This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH 1/2] Add support for O32 FPXX ABI
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "macro\ at codesourcery dot com" <macro at codesourcery dot com>, "Joseph Myers \(joseph\ at codesourcery dot com\)" <joseph at codesourcery dot com>, "binutils\ at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 07 Apr 2014 14:21:11 +0100
- Subject: Re: [PATCH 1/2] Add support for O32 FPXX ABI
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023534DAAAB at LEMAIL01 dot le dot imgtec dot org> <87a9c0xkje dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534DC37D at LEMAIL01 dot le dot imgtec dot org> <87ha655s3i dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B023534DC8CF at LEMAIL01 dot le dot imgtec dot org>
Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> Richard Sandiford <firstname.lastname@example.org> writes:
>> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
>> > Richard Sandiford <email@example.com> writes:
>> >> This information is really like the load-time equivalent of
>> >> .gnu_attributes.
>> >> .gnu_attributes collects the data into a single section and IMO the
>> >> segment side should too.
>> >> One representation would be to use the same data for the section and
>> >> the segment. Or, if the attributes format seems too complicated for
>> >> the loader, we could add a simple pre-digested structure (with a
>> >> version number as the first field, say).
>> > Given that any new segment would need to be handled (in some ways)
>> > like PT_NOTE then perhaps this does move the discussion towards
>> > When I say it is like PT_NOTE I mean that the segment data would want
>> > to be stored as close to the program headers as possible to reduce the
>> > amount of a file that needs to be read to check them. The cost of
>> > using PT_NOTE would be the string comparison for the note name and the
>> > risk of the notes being removed (I assume they can only be removed by
>> > specifically doing so, at which point all bets are off anyway). I
>> > believe notes have previously been rejected due to the string
>> comparisons though:
>> > http://sourceware.org/ml/binutils/2013-09/msg00099.html
>> > Assuming we go for having a new program header and a segment to hold
>> > the flags/structure... I could do with some pointers on how to go
>> > about creating the segment, creating the header was relatively easy as
>> > I had examples to go by but I can't see an example of creating a
>> > custom header with a segment/data. I'm also unsure of how to get such
>> > data to be placed close to the headers.
>> What did you think about the idea of reusing the .gnu_attributes section
>> data as the segment data? It seems simpler than the PT_NOTE format.
> I have no major objection. Slight concern over defining more of the MIPS
> ABI around the 'gnu' vendor attributes which is a bit strange given the
> MIPS architecture is not restricted to gnu tools. Having said that, MIPS is
> already using these as critical parts of the ABI and following it through
> to load time information as well then seems reasonable.
> In order to use the pre-existing section for GNU attributes I guess it
> would need to become SEC_ALLOC and get associated with the new program
Yeah, it should be SEC_ALLOC|SEC_LOAD for GNU/Linux, but I don't think
it should be for the baremetal *-elf targets (EMBEDDED=yes in the bfd
linker). This would match the .reginfo behaviour.
> Perhaps call it PT_MIPS_ATTRIBUTES or PT_GNU_ATTRIBUTES if this were
> done for all architectures.
Yeah. Might as well make it PT_GNU_ATTRIBUTES, even if it's something
that targets have to buy into. Probably worth sending a separate RFC
to the list for that.
> And then somehow get that to be positioned immediately after the notes
Yeah, at least in the case where it's loadable (and maybe otherwise too).
In the bfd linker this would be done by putting the .gnu_attributes in
the appropriate place in the linker script.