This is the mail archive of the binutils@sourceware.org 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, binutils] Patch elf/mips.h for -mfp64 support.


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




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