Re: [PATCH] MIPS gas/ld test suite portability fixes

[Richard Sandiford <rsandifo at redhat dot com>]

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