This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

> > 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 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
program headers.

> 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
quite soon.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]