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

  Maciej


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