RE: [PATCH 1/2] Add support for O32 FPXX ABI

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Richard Sandiford <rdsandiford@googlemail.com> writes:
> Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> > Richard Sandiford <rdsandiford@googlemail.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
> PT_NOTE.
> > 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.

Regards,
Matthew