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: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: Doug Gilmore <Doug dot Gilmore at imgtec dot com>, <binutils at sourceware dot org>
- Date: Wed, 11 Sep 2013 18:39:25 +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>
"Maciej W. Rozycki" <firstname.lastname@example.org> writes:
> 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.
Well, the R5900 was basically used as -mgp64 -mfp32. I agree it was
nonstandard, but it was used...
> 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.
Yeah, good point. EF_MIPS_GP32_FP64 might avoid that confusion while
still being more precise than EF_MIPS_FP64.
But I suppose I don't have a strong opinion either way. Doug, if neither
you nor Steve care, the patch is OK with EF_MIPS_FP64. In answer to your
other question, anyone can commit it.