This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] MIPS gas/ld test suite portability fixes
Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> Eric Christopher wrote:
>> > I meant something like:
>> >
>> > --- tc-mips.c 18 Feb 2005 22:12:50 -0000 1.284
>> > +++ tc-mips.c 22 Feb 2005 21:54:59 -0000
>> > @@ -10652,7 +10694,11 @@ mips_after_parse_args (void)
>> > }
>> >
>> > if (arch_info == 0)
>> > - arch_info = mips_parse_cpu ("default CPU", MIPS_CPU_STRING_DEFAULT);
>> > + {
>> > + arch_info = mips_parse_cpu ("default CPU", MIPS_CPU_STRING_DEFAULT);
>> > + if (ABI_NEEDS_64BIT_REGS (mips_abi) && !ISA_HAS_64BIT_REGS (arch_info->isa))
>> > + arch_info->isa = ISA_MIPS3;
>> > + }
>> >
>> > if (ABI_NEEDS_64BIT_REGS (mips_abi) && !ISA_HAS_64BIT_REGS (arch_info->isa))
>> > as_bad ("-march=%s is not compatible with the selected ABI",
>> >
>> >
>> > (This fails to compile because arch_info is a constant.)
>>
>> No, I definitely don't like this. It's going back to the era when
>> gcc/gas "guessed" what you meant.
Right. I'm strongly with Eric here.
Eric's already mentioned the old gcc behaviour of -mabi=64 implying
-mips4, but remember that -mabi=32 also used to imply -mips1, on the
basis that that's what the SVR4 ABI officially requires. But is that
what you want when you configure for sb1-elf or mipsisa32-elf?
How about when using mips64-linux-gnu configured with --with-arch=rm9000?
Should -mabi=32 override the --with-arch default?
Having -mabi change the architecture just leads to a mess. There are
so many different possible interpretations.
You say:
> It is not a guess in this case, and gcc uses the from-abi hack to
> figure it out correctly.
but I don't see it as a hack at all. It seems entirely consistent
with the idea that the architecture and ABI flags should be separate.
It was deliberately added as a separate architecture setting to cater
for the case where you always want the "most compatible" code possible.
And that's why it's the default for mips-* and mips64-* configurations
(meaning when --with-arch isn't used). Those configurations don't
imply that you're using a particular processor.
Your proposal seems to be catering for the case where:
(a) someone picks a 32-bit-only configuration that implies
a particular architecture; and
(b) then tries to use it to build 64-bit code.
Outside of running testsuites, who actually does that? It's a minor
market, surely? Anyone who's seriously interested in building 64-bit
code should use a 64-bit configuration, not something like mipstx39-elf,
mipsisa32-linux-gnu or whatever. That's especially true when you
consider that a 32-bit-only configuration won't build any compatible
libraries.
The current option handling dates from mid 2002:
http://sourceware.org/ml/binutils/2002-07/msg00463.html
http://sourceware.org/ml/binutils/2002-07/msg00463.html
and the current policy was discussed at length in the follow-up
messages. In particular, to quote from the second message:
--------------------------------------------------------------------------
6) The consensus seemed to be that, when using a configuration associated
with a particular ISA or processor, we should try to stick to the
default where possible. So "mips64orion-elf-gcc -mabi=32" would
generate 32-bit 4600 code rather than than MIPS I code.
Then, we would only deviate from the default architecture when that
architecture is a 32-bit one, and the selected ABI requires 64-bit
registers. For example, "mipstx39-elf -mabi=o64". For configs
like mipstx39-elf that are associated with a particular ISA, I
think specifying an incompatible ABI should be a hard error.
The user can of course say "mipstx39-elf -mabi=o64 -mips3" if
that's what they truly mean.
The question is, how do people see configs like mips-elf and
mips64-elf? Is mips-elf "a target for generating MIPS I code",
or (by a weaker definition) "a target that generates 32-bit code
by default". Similarly mips64-elf, MIPS III and 64-bit code.
According to the stronger definition, mips-elf-gcc would give
an error if you pass -mabi=o64 without changing the architecture.
According to the weaker definition, it should switch to MIPS III,
since -mabi=o64 obviously overrides the "32-bit" default. The
stronger definition implies the default should be -march=mips1,
while the weaker one implies it should be -march=from-abi.
Same sort of question for mips64-elf.
At the moment I'm leaning towards the weaker definition, so the patch
makes "from-abi" the default for both. Specifically, instead of
setting MIPS_ISA_DEFAULT to 3 in elf64.h and 1 in mips.h, there is
just a default definition of MIPS_CPU_STRING_DEFAULT as "from-abi".
That means the default behaviour is to select the "most compatible"
architecture for the given ABI, as Thiemo suggested.
--------------------------------------------------------------------------
As far as running the testsuite goes, I think we should either
apply something like Maciej's patch or simply disable these tests
for 32-bit configurations.
Richard