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

[Richard Sandiford <rdsandiford at googlemail dot com>]

Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> 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.

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
> segment.

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.

Thanks,
Richard