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

Thanks,
Richard