This is the mail archive of the
mailing list for the binutils project.
RE: [PATCH 1/2] Add support for O32 FPXX ABI
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail 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, 7 Apr 2014 12:20:37 +0000
- 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>
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
header. Perhaps call it PT_MIPS_ATTRIBUTES or PT_GNU_ATTRIBUTES if this
were done for all architectures. And then somehow get that to be positioned
immediately after the notes segment.