RE: [PATCH] Record whether an object attribute is actually set

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Richard Earnshaw <rearnsha@arm.com> writes:
> On 18/05/14 21:30, Matthew Fortune wrote:
> > Richard Sandiford <rdsandiford@googlemail.com> writes:
> >> Richard Sandiford <rdsandiford@googlemail.com> writes:
> >>> Sorry the slow reply to this.
> >>>
> >>> Alan Modra <amodra@gmail.com> writes:
> >>>> On Mon, May 12, 2014 at 11:22:13PM +0000, Matthew Fortune wrote:
> >>>>> --- a/bfd/elf-bfd.h
> >>>>> +++ b/bfd/elf-bfd.h
> >>>>> @@ -1472,6 +1472,7 @@ typedef struct obj_attribute
> >>>>>    int type;
> >>>>>    unsigned int i;
> >>>>>    char *s;
> >>>>> +  bfd_boolean is_set;
> >>>>>  } obj_attribute;
> >>>>
> >>>> Note that, because someone added a 2 * 71 array of this struct to
> >>>> elf_obj_data, all ELF object BFDs get hit by any increase here,
> >>>> whether the files use attributes or not.  Can you do without the flag,
> >>>> somehow?
> >>>
> >>> Yeah, I was more thinking about having a flag in the assembler,
> >>> since I think we want to know whether the attribute has been set
> >>> by an explicit .gnu_attribute in the code, rather than through
> >>> some implicit setting.
> >>>
> >>> How about the attached look?
> >>
> >> Er, that's what happens you change your mind between "how does the
> >> attached look" and "how about the attached" half-way through the
> sentence.
> >
> > At least it didn't turn into complete gibberish which I'm sure I'll
> > manage one day!
> >
> > Sorry for not getting back to you sooner, I wanted to run it with the
> FPXX
> > tests and had a half broken testsuite as I was working on it. This looks
> > good. I don't think there was much value in the end in the flag being
> > stored directly in the attributes as its meaning would have been fuzzy at
> > link time.
> >
> > Thanks,
> > Matthew
> >
> 
> [With apologies if you already know all of this].
> 
> Hmm, there's a "beware of dragons" warning here.
> 
> The attributes model, which IIRC is derived from the ARM ABI attributes
> model, works on the principle that if an object file does not explicitly
> specify a value for an attribute, then it takes its default value (for
> numeric attributes that's normally 0).
> 
> So the important thing to remember when adding new attributes is that
> they aren't really new: they've always existed, even before they were
> specified -- but old object files have always set the value to default.
> 
> What does that mean?  Well the key point is that you have to pick your
> default quite carefully, so that it means what that object probably
> would have done anyway.  At other times, the default might have to mean
> "I don't care" or "I won't say" and you then have to trust the object to
> have got things right.
> 
> Beware of defining new attributes where the default is never useful,
> though, so that new objects have to define it to some non-zero value.
> They'll bloat object files if you have too many of them.  They'll also
> make assembler files more tricky to write.

Thanks Richard, I was aware of this but it is a useful reminder anyway.
The work I am doing currently is adding new values to an existing
attribute tag. The attribute being extended is the tag for floating-point
ABI and the new feature is that an ABI is automatically inferred based
on command line options. The reason for this patch is that I need to be
able to distinguish between an assembly input which explicitly defines
the default value (which has a useful meaning) and one which has no such
explicit directive. I only infer an ABI if the user did not explicitly
set one.

Regards,
Matthew