This is the mail archive of the
mailing list for the binutils project.
RE: [PATCH 1/2] Add support for O32 FPXX ABI
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail 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: Tue, 15 Apr 2014 21:09:40 +0000
- 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>
> > 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.
> I agree it'd be possible to use .MIPS.options, but in some ways it seems
> a bit heavyweight for what we want. Like with PT_NOTE, looking up the
> data would involve a search for the right kind. In this case we'd be
> searching for an integer rather than a string, so it's much less of a
> problem, but it still seems like an unnecessary overhead.
> FWIW, looking at an n64 libc.so I have lying around, the .MIPS.options
> is 0xe948 bytes in size.
Indeed not small.
> 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
> 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.
I don't have enough knowledge of other architectures to know how common
special sections, segments, headers are but I get the feeling MIPS already
has more than most. Avoiding new ones (and/or propagating existing ones
to more ABIs) may reduce the confusion over the different ABIs.
I too am still open to ideas here but I do need to settle on something
If I start the implementation by extending .MIPS.options perhaps others
may chime in with their opinions... Moving to a different section should
only be the matter of duplicating the code for .MIPS.options so won't
cause too much pain if we settle on that.