This is the mail archive of the
mailing list for the binutils project.
Re: [patch, binutils] Patch elf/mips.h for -mfp64 support.
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Jack Carter <Jack dot Carter at imgtec dot com>
- Cc: "Maciej W. Rozycki" <macro at codesourcery dot com>, Doug Gilmore <Doug dot Gilmore at imgtec dot com>, "binutils\ at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 18 Sep 2013 09:53:09 +0100
- Subject: Re: [patch, binutils] Patch elf/mips.h for -mfp64 support.
- Authentication-results: sourceware.org; auth=none
- References: <522E6DDF dot 10909 at imgtec dot com> <87sixdf64s dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1309100948050 dot 29360 at tp dot orcam dot me dot uk> <87ppsgmnjn dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1309111352360 dot 29360 at tp dot orcam dot me dot uk> <5238A87D dot 5080006 at imgtec dot com> <alpine dot DEB dot 1 dot 10 dot 1309172352370 dot 4379 at tp dot orcam dot me dot uk> <4CEFBC1BE64A8048869F799EF2D2EEEE01AB550C at BADAG02 dot ba dot imgtec dot org>
Jack Carter <Jack.Carter@imgtec.com> writes:
>> From: Maciej W. Rozycki [email@example.com]
>> Sent: Tuesday, September 17, 2013 4:10 PM
>> To: Jack Carter
>> Cc: Richard Sandiford; Doug Gilmore; firstname.lastname@example.org
>> Subject: Re: [patch, binutils] Patch elf/mips.h for -mfp64 support.
>> [Usenet cross-posting stripped, no usable NNTP server here, sigh...]
>> On Tue, 17 Sep 2013, Jack Carter wrote:
>> > Hehe, actually I reckon I have once raised the issue somewhere already
>> > and I can surely do it again, though I think it will be wise to think
>> > ahead and have an idea what the extension might look like as I'm sure the
>> > need for it is bound to happen sooner rather than later.
>> Are talking about the PT_NOTE segment and .note section? If so, that is
>> described in the System V abi circa '92 and is very simple.
>> Yes, we've been using these sections/segments for a while already
>> although for a different purpose (see csu/abi-note.S in glibc).
> Well do we want to do what SGI did and is documented in the 64-bit ELF
> Object File Specification and use the Options section? I would think
> that the NOTE segment would be the more generic way to go, but if it
> is being used for different purposes maybe we have no choice.
I think Maciej's point was that we're already using PT_NOTE in the
standard way. It's a different purpose because we're not using it
to replace ELF flag information, but it's still the standard way.
FWIW I don't think PT_NOTE is the best choice for what we're discussing
here though. PT_NOTE a good way of adding nonstandard data, or data that
doesn't need to be examined for correct execution. But here we're talking
about something that the loader really should look at.
I'd prefer we ate up one of the processor-specific headers instead
(i.e. PT_LOPROC + X for some X). There's millions of those free,
so we're not likely to run out. That would mean that the loader
would only need to search the header table, without any of the string
searches inherent in using PT_NOTE.