This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] Record whether an object attribute is actually set
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: Richard Sandiford <rdsandiford at googlemail dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 19 May 2014 15:40:47 +0100
- Subject: Re: [PATCH] Record whether an object attribute is actually set
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235352C2DA at LEMAIL01 dot le dot imgtec dot org> <20140516082705 dot GV5162 at bubble dot grove dot modra dot org> <87wqdkyavu dot fsf at talisman dot default> <87d2fanb8b dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023535345A9 at LEMAIL01 dot le dot imgtec dot org>
On 18/05/14 21:30, Matthew Fortune wrote:
> Richard Sandiford <firstname.lastname@example.org> writes:
>> Richard Sandiford <email@example.com> writes:
>>> Sorry the slow reply to this.
>>> Alan Modra <firstname.lastname@example.org> 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,
>>> 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.
[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.