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 11:52:49 +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>
Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> Richard Sandiford <firstname.lastname@example.org> writes:
>> This information is really like the load-time equivalent of
>> .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:
> 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.