This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

R.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]