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>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>
- Date: Wed, 16 Apr 2014 09:24:53 +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> <87ha655s3i dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B023534DC8CF at LEMAIL01 dot le dot imgtec dot org> <871tx9z35k dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B023534DFC40 at LEMAIL01 dot le dot imgtec dot org> <878urd37t7 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B023534DFD9B at LEMAIL01 dot le dot imgtec dot org> <87fvll1ha9 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <6D39441BF12EF246A7ABCE6654B023534E07CB at LEMAIL01 dot le dot imgtec dot org> <87k3awnuf1 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534E0F50 at LEMAIL01 dot le dot imgtec dot org> <87ppknzv7m dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534E16D7 at LEMAIL01 dot le dot imgtec dot org> <877g6vzpj1 dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534E3030 at LEMAIL01 dot le dot imgtec dot org> <87eh0yl4xx dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B023534E3AA8 at LEMAIL01 dot le dot imgtec dot org>
Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
>> > I've been reviewing the .MIPS.options section to see whether it would
>> > be a suitable place for storing this new information and from what I
>> > can tell it would fit quite nicely. The .MIPS.options section is only
>> > emitted for
>> > N64 currently but I don't see any technical reason why it cannot be
>> > emitted for 32-bit or 64-bit ELFs so I would propose using it for all
>> > 3 of the most used ABIs (O32, N32, N64). Perhaps going so far as to
>> > stop emitting the .reginfo section for O32 and N32 as that information
>> > fits into the .MIPS.options section anyway. The structure of this
>> > section is quite neat in that the option descriptor header states the
>> > total size of the header+payload and therefore can be easily skipped.
>> > The maximum payload per descriptor is 255 bytes including the 8 byte
>> > header but that does not seem restrictive. I would add a new
>> > descriptor type and be able to re-use a reasonable amount of existing
>> > code. There is a program header and dynamic tag already defined for
>> > this section which are only emitted for irix currently but that is
>> easily resolved.
>> How much code would it save though? It means you don't have to define a
>> new header, but that's only a small saving.
> It's more that I realised the structure of the .MIPS.options section is
> quite closely matched to what I need and its treatment throughout the tools
> is precisely the way I would need a new section to behave. It's the special
> cases needed to handle a new section type throughout the tools which would
> end up not being needed. The section name is also likely to be very similar
> to .MIPS.options i.e. .MIPS.flags.
But like you say, DT_MIPS_OPTIONS is currently only used for IRIX 6,
so I doubt any of the loaders we're likely to care about handle it yet.
And when we add the support, having a list of blocks that you need to
search is going to be more complicated than having a single block.
It might save a few lines in the linkers, but I don't think the saving
there would be too big and it doesn't seem like the right thing to optimise
To put it another way, what's in .MIPS.options at the moment isn't in
practice useful for non-IRIX loaders. What we're adding is. And program
headers already divide up the data nicely, so I don't we need need a
.MIPS.options-style grouping structure on top of that.
>> I suppose you could add a rule that the new kind needs to come first,
>> but that doesn't seem in the spirit of the thing. If we're adding
>> special rules like that then we might as well add a new header instead.
> My thinking was that we will be displacing the .MIPS.options or .reginfo
> segment by introducing something new next to the program headers. Given
> these segments are recommended to follow the program headers it could be
> conflicting to say that a newly proposed segment also must follow the
> program headers.
Yeah, but that's just documentation. :-) When adding something we get to
say how it interacts with existing features.
>> Also, like you say, it would involve either a change to the ELF32 ABIs
>> or having duplicated information there. We'd probably have to go for
>> the duplicated information since .reginfo is part of the psABI.
> I don't particularly see that the reginfo descriptor has to be mandatory
> for the ELF32 ABIs so we could avoid the duplication even not that it is
> much of a saving.
.reginfo is needed in ET_RELs because it gives the value of GP0, which is
needed to handle GP-relative relocations correctly. I think we'd need to
keep it for those at least. Maybe it isn't as important for fully-linked
objects, but if we're keeping it for relocatable objects we might as well
keep it for all objects.