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

Jack Carter jack.carter@imgtec.com
Tue Sep 17 19:07:00 GMT 2013


On 09/11/2013 06:26 AM, Maciej W. Rozycki wrote:
> On Tue, 10 Sep 2013, Richard Sandiford wrote:
>
>>>   Also how about just EF_MIPS_FP64 for brevity and to match the name
>>> chosen for the corresponding attribute?
>>
>> That might be a bit confusing though, since we only set it for -mgp32 -mfp64,
>> not normal -mgp64 -mfp64.
>
>   It may or it may not.  I don't think we need to carry all the available
> information in macro names, this is what documentation is for (a revised
> MIPS psABI document would be most welcome as the latest stuff we've got
> from SGI has by now become painfully obsolete).  An -mgp64 -mfp32 ABI is
> non-standard, I doubt anyone uses such a configuration, so for any
> practical purposes it has always been a norm that GP64 ABIs also have
> 64-bit FPRs.  So I believe it'll be generally understood that the flag is
> only there to denote the exceptional use of 64-bit FPRs with a GP32 ABI.
>
>   And I find it more confusing that EF_MIPS_32BITMODE_FP64 is so similar to
> EF_MIPS_32BITMODE while the two are not related to each other at all --
> the former asks for a 64-bit FPU for 32-bit code while the latter says
> code is 32-bit even though the ISA level is 64-bit.  And the latter flag
> is actually a good precedent -- just as we don't set EF_MIPS_32BITMODE for
> all 32-bit code (e.g. my MIPS I binaries don't have it set even though
> they are firm-32-bit code), we won't set the new flag for all 64-bit FPU
> code.  So just as we don't call the former flag EF_MIPS_GP64_32BITMODE or
> whatever we don't have to call the new flag EF_MIPS_32BITMODE_FP64 either.
>
>>>   Indeed, we may need to switch to ELF notes at one point.  One of the bits
>>> left, presumably 0x00000800, may be useful to denote the need to refer
>>> interpreters to such notes (for performance reasons, e.g. for the kernel
>>> so that it doesn't look notes up where there isn't one).
>>
>> Yeah, keeping 0x800 in reserve as some kind of extension escape sounds
>> like a good idea to me FWIW.  I think you tend to hear about these new
>> flags before I do, so please push for that if you get chance!
>
>   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.

>
>    Maciej
>




More information about the Binutils mailing list