[patch, binutils] Patch elf/mips.h for -mfp64 support.

[Richard Sandiford]

Jack Carter <Jack.Carter@imgtec.com> writes:
> ________________________________________
>> From: Maciej W. Rozycki [macro@codesourcery.com]
>> Sent: Tuesday, September 17, 2013 4:10 PM
>> To: Jack Carter
>> Cc: Richard Sandiford; Doug Gilmore; binutils@sourceware.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.

Thanks,
Richard