This is the mail archive of the
mailing list for the binutils project.
RE: [PATCH] Record whether an object attribute is actually set
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Richard Earnshaw <rearnsha at arm dot com>
- Cc: Richard Sandiford <rdsandiford at googlemail dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Tue, 20 May 2014 08:43:15 +0000
- 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> <537A17EF dot 4040502 at arm dot com>
Richard Earnshaw <email@example.com> writes:
> 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,
> >>>> 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
> > 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
> > 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