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

[Richard Sandiford <rdsandiford at googlemail dot com>]

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
for anyway.

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.

Thanks,
Richard