MIPS: gas: alter 64 or 32 for r6 triples if march is implicit

  When configure with triples mipsisa[32,64]r6[el,], the march value
is pinned to a fix value if not given explicitly. for example
   mipsisa32r6-linux-gnu -n32 xx.s
will complains that:
   -march=mips32r6 is not compatible with the selected ABI

Since we are using these triples as a regular linux distributions,
let's alter march according to ABI.
---
 gas/config/tc-mips.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
  

> 2023年5月6日 09:37，YunQiang Su <yunqiang.su@cipunited.com> 写道：
> 
> When configure with triples mipsisa[32,64]r6[el,], the march value
> is pinned to a fix value if not given explicitly. for example
>   mipsisa32r6-linux-gnu -n32 xx.s
> will complains that:
>   -march=mips32r6 is not compatible with the selected ABI
> 
> Since we are using these triples as a regular linux distributions,
> let's alter march according to ABI.

Hi,

Hmm, why people wants to build n32 binary on mips32r6 CPU?
For multiline folks they should use mipsisa64r6 base triple which will accept
all 3 ABIs.

Thanks
Jiaxun


> ---
> gas/config/tc-mips.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
> 
> diff --git a/gas/config/tc-mips.c b/gas/config/tc-mips.c
> index 8a970ceada2..d99736df26a 100644
> --- a/gas/config/tc-mips.c
> +++ b/gas/config/tc-mips.c
> @@ -20247,6 +20247,24 @@ mips_parse_cpu (const char *option, const char *cpu_string)
>     : ISA_MIPS1);
>     }
> 
> +  /* mipsisa32r6-linux-gnu refuses -n32/-64 swtiches:
> + -march=mips32r6 is not compatible with the selected ABI
> +     Let's workaround it when -march options are not given explicitly.
> +     We treat it some like -march=from-abi */
> +  if ((strcasecmp (cpu_string, "mips32r6") == 0 || strcasecmp (cpu_string, "mips64r6") == 0)
> + && strcasecmp (option, "default CPU") == 0)
> +    {
> +      if (ABI_NEEDS_32BIT_REGS (mips_abi))
> + return mips_cpu_info_from_isa (ISA_MIPS32R6);
> +
> +      if (ABI_NEEDS_64BIT_REGS (mips_abi))
> + return mips_cpu_info_from_isa (ISA_MIPS64R6);
> +
> +      if (file_mips_opts.gp >= 0)
> + return mips_cpu_info_from_isa (file_mips_opts.gp == 32
> +       ? ISA_MIPS32R6 : ISA_MIPS64R6);
> +    }
> +
>   /* 'default' has traditionally been a no-op.  Probably not very useful.  */
>   if (strcasecmp (cpu_string, "default") == 0)
>     return 0;
> -- 
> 2.30.2
>
  

Jiaxun Yang <jiaxun.yang@flygoat.com> 于2023年5月6日周六 16:43写道：
>
>
>
> > 2023年5月6日 09:37，YunQiang Su <yunqiang.su@cipunited.com> 写道：
> >
> > When configure with triples mipsisa[32,64]r6[el,], the march value
> > is pinned to a fix value if not given explicitly. for example
> >   mipsisa32r6-linux-gnu -n32 xx.s
> > will complains that:
> >   -march=mips32r6 is not compatible with the selected ABI
> >
> > Since we are using these triples as a regular linux distributions,
> > let's alter march according to ABI.
>
> Hi,
>
> Hmm, why people wants to build n32 binary on mips32r6 CPU?

I guess o32 toolchain should not work only for 32bit CPU?

At seem time, this patch can solve some testcases in binutils-all
when configured with
       --target=mipsisa32r6-linux-gnu

> For multiline folks they should use mipsisa64r6 base triple which will accept
> all 3 ABIs.
>
> Thanks
> Jiaxun
>
>
> > ---
> > gas/config/tc-mips.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/gas/config/tc-mips.c b/gas/config/tc-mips.c
> > index 8a970ceada2..d99736df26a 100644
> > --- a/gas/config/tc-mips.c
> > +++ b/gas/config/tc-mips.c
> > @@ -20247,6 +20247,24 @@ mips_parse_cpu (const char *option, const char *cpu_string)
> >     : ISA_MIPS1);
> >     }
> >
> > +  /* mipsisa32r6-linux-gnu refuses -n32/-64 swtiches:
> > + -march=mips32r6 is not compatible with the selected ABI
> > +     Let's workaround it when -march options are not given explicitly.
> > +     We treat it some like -march=from-abi */
> > +  if ((strcasecmp (cpu_string, "mips32r6") == 0 || strcasecmp (cpu_string, "mips64r6") == 0)
> > + && strcasecmp (option, "default CPU") == 0)
> > +    {
> > +      if (ABI_NEEDS_32BIT_REGS (mips_abi))
> > + return mips_cpu_info_from_isa (ISA_MIPS32R6);
> > +
> > +      if (ABI_NEEDS_64BIT_REGS (mips_abi))
> > + return mips_cpu_info_from_isa (ISA_MIPS64R6);
> > +
> > +      if (file_mips_opts.gp >= 0)
> > + return mips_cpu_info_from_isa (file_mips_opts.gp == 32
> > +       ? ISA_MIPS32R6 : ISA_MIPS64R6);
> > +    }
> > +
> >   /* 'default' has traditionally been a no-op.  Probably not very useful.  */
> >   if (strcasecmp (cpu_string, "default") == 0)
> >     return 0;
> > --
> > 2.30.2
> >
>
  

> 2023年5月6日 09:52，YunQiang Su <syq@debian.org> 写道：
> 
> Jiaxun Yang <jiaxun.yang@flygoat.com> 于2023年5月6日周六 16:43写道：
>> 
>> 
>> 
>>> 2023年5月6日 09:37，YunQiang Su <yunqiang.su@cipunited.com> 写道：
>>> 
>>> When configure with triples mipsisa[32,64]r6[el,], the march value
>>> is pinned to a fix value if not given explicitly. for example
>>>  mipsisa32r6-linux-gnu -n32 xx.s
>>> will complains that:
>>>  -march=mips32r6 is not compatible with the selected ABI
>>> 
>>> Since we are using these triples as a regular linux distributions,
>>> let's alter march according to ABI.
>> 
>> Hi,
>> 
>> Hmm, why people wants to build n32 binary on mips32r6 CPU?
> 
> I guess o32 toolchain should not work only for 32bit CPU?

In this case people should override -march option themself, not rely on random
toolchain hacks, since it’s not determinant from user’s perspective what “fallback”
march it will be, especially in case the toolchain is not designed for base ISA.

> 
> At seem time, this patch can solve some testcases in binutils-all
> when configured with
>       --target=mipsisa32r6-linux-gnu

I think we’d better fix the test case.

Thanks
Jiaxun
  

On Sat, 6 May 2023, Jiaxun Yang wrote:

> >> Hmm, why people wants to build n32 binary on mips32r6 CPU?
> > 
> > I guess o32 toolchain should not work only for 32bit CPU?
> 
> In this case people should override -march option themself, not rely on random
> toolchain hacks, since it’s not determinant from user’s perspective what “fallback”
> march it will be, especially in case the toolchain is not designed for base ISA.

 Seconded.  If anyhow, I'd suggest changing the arrangement the GCC way, 
that is by adding `--with-arch-32=' and `--with-arch-64=' configuration 
options.  I'm not terribly convinced however that would be a worthwhile 
improvement, because GAS shouldn't normally be invoked directly, and when 
called via the GCC driver the driver will do the right thing.

 YunQiang, do you actually have a use case for invoking GAS directly?  I 
only do it when debugging GAS, which is sort of irrelevant.  For normal 
compilations I never do it.

  Maciej
  

> 2023年5月7日 19:17，Maciej W. Rozycki <macro@orcam.me.uk> 写道：
> 
> On Sat, 6 May 2023, Jiaxun Yang wrote:
> 
>>>> Hmm, why people wants to build n32 binary on mips32r6 CPU?
>>> 
>>> I guess o32 toolchain should not work only for 32bit CPU?
>> 
>> In this case people should override -march option themself, not rely on random
>> toolchain hacks, since it’s not determinant from user’s perspective what “fallback”
>> march it will be, especially in case the toolchain is not designed for base ISA.
> 
> Seconded.  If anyhow, I'd suggest changing the arrangement the GCC way, 
> that is by adding `--with-arch-32=' and `--with-arch-64=' configuration 
> options.  I'm not terribly convinced however that would be a worthwhile 
> improvement, because GAS shouldn't normally be invoked directly, and when 
> called via the GCC driver the driver will do the right thing.
> 
> YunQiang, do you actually have a use case for invoking GAS directly?  I 
> only do it when debugging GAS, which is sort of irrelevant.  For normal 
> compilations I never do it.

The issue was raised by Glib[1], they are involving `ld` directly.

I recall v8 was generating embedded data as assembly directives and then invoking as to
generate object file. They claimed it’s faster than GCC.

I think it make sense to get this “workaround” done in GAS/LD, but not in this way.
 `--with-arch-32=' and `--with-arch-64=` method fits the purpose better. 

Thanks
Jiaxun

[1]: https://gitlab.gnome.org/GNOME/glib/-/issues/2768
> 
>  Maciej
  

On Sun, 7 May 2023, Jiaxun Yang wrote:

> > YunQiang, do you actually have a use case for invoking GAS directly?  I 
> > only do it when debugging GAS, which is sort of irrelevant.  For normal 
> > compilations I never do it.
> 
> The issue was raised by Glib[1], they are involving `ld` directly.

 That's a bug in Glib then, LD is not supposed to be invoked directly with 
user compilations.  For one correct multilib options won't be applied and 
if Glib strives to extract them from GCC invocation somehow, then good 
luck!

 The issue claims they want to call `ld -r' to get a relocatable link.  
Why don't they just call `gcc -r' to the same effect in a supported way?

  Maciej
  

Maciej W. Rozycki <macro@orcam.me.uk> 于2023年5月8日周一 03:01写道：
>
> On Sun, 7 May 2023, Jiaxun Yang wrote:
>
> > > YunQiang, do you actually have a use case for invoking GAS directly?  I
> > > only do it when debugging GAS, which is sort of irrelevant.  For normal
> > > compilations I never do it.
> >
> > The issue was raised by Glib[1], they are involving `ld` directly.
>
>  That's a bug in Glib then, LD is not supposed to be invoked directly with
> user compilations.  For one correct multilib options won't be applied and
> if Glib strives to extract them from GCC invocation somehow, then good
> luck!
>

As my experience of working on Linux distributions, lots of softwares invoke
gas/ld directly.

For Glib's aspect, it expects the system's toolchain so the right thing,
So it is not a bug.

>  The issue claims they want to call `ld -r' to get a relocatable link.
> Why don't they just call `gcc -r' to the same effect in a supported way?
>

In fact it doesn't work:

syq@vm-1:~$ mipsisa32r6el-linux-gnu-gcc -r xx.dat -o xx.o && file xx.o
xx.o: ELF 32-bit LSB relocatable, MIPS, MIPS-I version 1 (SYSV), not stripped

>   Maciej
  

Jiaxun Yang <jiaxun.yang@flygoat.com> 于2023年5月8日周一 02:35写道：
>
>
>
> > 2023年5月7日 19:17，Maciej W. Rozycki <macro@orcam.me.uk> 写道：
> >
> > On Sat, 6 May 2023, Jiaxun Yang wrote:
> >
> >>>> Hmm, why people wants to build n32 binary on mips32r6 CPU?
> >>>
> >>> I guess o32 toolchain should not work only for 32bit CPU?
> >>
> >> In this case people should override -march option themself, not rely on random
> >> toolchain hacks, since it’s not determinant from user’s perspective what “fallback”
> >> march it will be, especially in case the toolchain is not designed for base ISA.
> >
> > Seconded.  If anyhow, I'd suggest changing the arrangement the GCC way,
> > that is by adding `--with-arch-32=' and `--with-arch-64=' configuration
> > options.  I'm not terribly convinced however that would be a worthwhile
> > improvement, because GAS shouldn't normally be invoked directly, and when
> > called via the GCC driver the driver will do the right thing.
> >
> > YunQiang, do you actually have a use case for invoking GAS directly?  I
> > only do it when debugging GAS, which is sort of irrelevant.  For normal
> > compilations I never do it.
>
> The issue was raised by Glib[1], they are involving `ld` directly.
>
> I recall v8 was generating embedded data as assembly directives and then invoking as to
> generate object file. They claimed it’s faster than GCC.
>
> I think it make sense to get this “workaround” done in GAS/LD, but not in this way.
>  `--with-arch-32=' and `--with-arch-64=` method fits the purpose better.
>

My worry about the --with-arch-32/64 is that: somebody may create a
toolchain like this:

../configure --target=mipsisa64r6el-linux-gnu --with-arch-32=mips32
--with-arch-64=mips64r2

> Thanks
> Jiaxun
>
> [1]: https://gitlab.gnome.org/GNOME/glib/-/issues/2768
> >
> >  Maciej
>
  

On Mai 07 2023, Jiaxun Yang via Binutils wrote:

> The issue was raised by Glib[1], they are involving `ld` directly.

Since commit 6d93568e3 they don't appear to do that any more.
  

Andreas Schwab via Binutils <binutils@sourceware.org> 于2023年5月8日周一 17:40写道：
>
> On Mai 07 2023, Jiaxun Yang via Binutils wrote:
>
> > The issue was raised by Glib[1], they are involving `ld` directly.
>
> Since commit 6d93568e3 they don't appear to do that any more.
>

Thanks for your information, and I have a test, it still cannot work
with the MIPS case.
Maybe MIPS's compiler should pass more options to linker then.

Does linker accept an runtime option for ISA level?
Let me have a check.

> --
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
  

On Mon, 8 May 2023, YunQiang Su wrote:

> >  That's a bug in Glib then, LD is not supposed to be invoked directly with
> > user compilations.  For one correct multilib options won't be applied and
> > if Glib strives to extract them from GCC invocation somehow, then good
> > luck!
> 
> As my experience of working on Linux distributions, lots of softwares invoke
> gas/ld directly.

 It doesn't make them correct.  Lots of software packages, though maybe 
fewer these days, also break in a cross-compilation environment.  Both 
cases are unfortunate, but not our problem to work around.

> >  The issue claims they want to call `ld -r' to get a relocatable link.
> > Why don't they just call `gcc -r' to the same effect in a supported way?
> 
> In fact it doesn't work:
> 
> syq@vm-1:~$ mipsisa32r6el-linux-gnu-gcc -r xx.dat -o xx.o && file xx.o
> xx.o: ELF 32-bit LSB relocatable, MIPS, MIPS-I version 1 (SYSV), not stripped

 You'll need to debug it them, because LD overall is supposed to propagate 
ISA flags correctly, and it actually works here:

$ cat foo.s
foo:
	move	$2, $3
$ mips-linux-gnu-gcc -march=mips32r2 -c foo.s -o foo-r2.o
$ mips-linux-gnu-gcc -march=mips32r6 -c foo.s -o foo-r6.o
$ mips-linux-gnu-gcc -march=mips32r2 -r foo-r2.o -o foo-r2-r.o
$ mips-linux-gnu-gcc -march=mips32r6 -r foo-r6.o -o foo-r6-r.o
$ file foo*.o
foo-r2-r.o: ELF 32-bit MSB relocatable, MIPS, MIPS32 rel2 version 1 (SYSV), notstripped
foo-r2.o:   ELF 32-bit MSB relocatable, MIPS, MIPS32 rel2 version 1 (SYSV), notstripped
foo-r6-r.o: ELF 32-bit MSB relocatable, MIPS, MIPS32 rel6 version 1 (SYSV), notstripped
foo-r6.o:   ELF 32-bit MSB relocatable, MIPS, MIPS32 rel6 version 1 (SYSV), notstripped
$ mips-linux-gnu-ld --version
GNU ld (GNU Binutils) 2.39.50.20221112
[...]

Maybe it's a recent regression?

 Or is glib trying to make an ELF object out of a non-ELF one, so input 
doesn't have correct flags/attributes set?  That's not really supported, 
they need to get at their input data through an assembly source, via the 
`.incbin' pseudo-op (invented many years ago to solve this very problem). 
I was bitten by this issue decades ago too, even before `.incbin' existed.

  Maciej
  

Maciej W. Rozycki <macro@orcam.me.uk> 于2023年5月8日周一 20:25写道：
>
> On Mon, 8 May 2023, YunQiang Su wrote:
>
> > >  That's a bug in Glib then, LD is not supposed to be invoked directly with
> > > user compilations.  For one correct multilib options won't be applied and
> > > if Glib strives to extract them from GCC invocation somehow, then good
> > > luck!
> >
> > As my experience of working on Linux distributions, lots of softwares invoke
> > gas/ld directly.
>
>  It doesn't make them correct.  Lots of software packages, though maybe
> fewer these days, also break in a cross-compilation environment.  Both
> cases are unfortunate, but not our problem to work around.
>
> > >  The issue claims they want to call `ld -r' to get a relocatable link.
> > > Why don't they just call `gcc -r' to the same effect in a supported way?
> >
> > In fact it doesn't work:
> >
> > syq@vm-1:~$ mipsisa32r6el-linux-gnu-gcc -r xx.dat -o xx.o && file xx.o
> > xx.o: ELF 32-bit LSB relocatable, MIPS, MIPS-I version 1 (SYSV), not stripped
>
>  You'll need to debug it them, because LD overall is supposed to propagate
> ISA flags correctly, and it actually works here:
>
> $ cat foo.s
> foo:
>         move    $2, $3
> $ mips-linux-gnu-gcc -march=mips32r2 -c foo.s -o foo-r2.o
> $ mips-linux-gnu-gcc -march=mips32r6 -c foo.s -o foo-r6.o
> $ mips-linux-gnu-gcc -march=mips32r2 -r foo-r2.o -o foo-r2-r.o
> $ mips-linux-gnu-gcc -march=mips32r6 -r foo-r6.o -o foo-r6-r.o
> $ file foo*.o
> foo-r2-r.o: ELF 32-bit MSB relocatable, MIPS, MIPS32 rel2 version 1 (SYSV), notstripped
> foo-r2.o:   ELF 32-bit MSB relocatable, MIPS, MIPS32 rel2 version 1 (SYSV), notstripped
> foo-r6-r.o: ELF 32-bit MSB relocatable, MIPS, MIPS32 rel6 version 1 (SYSV), notstripped
> foo-r6.o:   ELF 32-bit MSB relocatable, MIPS, MIPS32 rel6 version 1 (SYSV), notstripped
> $ mips-linux-gnu-ld --version
> GNU ld (GNU Binutils) 2.39.50.20221112
> [...]
>
> Maybe it's a recent regression?
>
>  Or is glib trying to make an ELF object out of a non-ELF one, so input
> doesn't have correct flags/attributes set?  That's not really supported,

Yes. That is the problem I try to workaround: GLib try to convert a
pure data file to an ELF object.

> they need to get at their input data through an assembly source, via the
> `.incbin' pseudo-op (invented many years ago to solve this very problem).
> I was bitten by this issue decades ago too, even before `.incbin' existed.
>

Yes. You introduced this option to me, while
1) GLib guys refused this way
2) Few peopel know about.

If most of any arch can work, but us, it's MIPS's bug: we cannot
change the whole world.

>   Maciej
  

On Mon, 8 May 2023, YunQiang Su wrote:

> > they need to get at their input data through an assembly source, via the
> > `.incbin' pseudo-op (invented many years ago to solve this very problem).
> > I was bitten by this issue decades ago too, even before `.incbin' existed.
> >
> 
> Yes. You introduced this option to me, while
> 1) GLib guys refused this way

 What can I say?  If you find a bug in a piece of software and its authors 
refuse to fix it, then perhaps they should change industry as they have an 
attitude problem.

 I've seen it before, I once reported a crash due to a stack overrun (an 
access was made beyond the bottom of the stack, which wasn't mapped) in a 
proprietary binary library we used at my previous job place and the vendor 
refused to debug and fix it claiming it cannot happen.  We stopped working 
with said vendor.

 Maintainers of other software packages do not appear to have this problem 
and accept that they may have made a mistake.  I don't remember where I've 
last seen a piece of software converted to use `.incbin' for portability 
reasons, but I did see it happen.  Also search the Internet for `"objcopy" 
"incbin"' and see how often the matter pops up.

> 2) Few peopel know about.

 Well, software development is a complex matter and competence is unevenly 
spread I suppose.  We've had this pseudo-op for over 20 years now: 
<https://sourceware.org/legacy-ml/binutils/2001-06/msg00817.html> and it 
isn't unique to GAS according to the originator.

> If most of any arch can work, but us, it's MIPS's bug: we cannot
> change the whole world.

 It's not a MIPS bug, and I have seen it elsewhere too.  For example: 
<https://lists.gnu.org/archive/html/bug-binutils/2014-01/msg00037.html>.  
Software maintainers need to accept all the world's not a VAX/x86/whatever 
and that if something works by chance in the majority of cases, it does 
not mean it is correct.

 You're right in that we can't fix all the world though, so if maintainers
of a given piece of software cannot be persuaded to accept a valid fix, 
you can still keep the fix locally or drop the package.

  Maciej
  

On Mon, 8 May 2023, Maciej W. Rozycki wrote:

> > If most of any arch can work, but us, it's MIPS's bug: we cannot
> > change the whole world.
> 
>  It's not a MIPS bug, and I have seen it elsewhere too.  For example: 
> <https://lists.gnu.org/archive/html/bug-binutils/2014-01/msg00037.html>.  
> Software maintainers need to accept all the world's not a VAX/x86/whatever 
> and that if something works by chance in the majority of cases, it does 
> not mean it is correct.

 To be fair we might well suppress setting and/or verifying ISA, ASE, PIC, 
etc. flags for object files that only contain data (i.e. no SHF_EXECINTR 
sections), because such annotation is only relevant to executable code.  
This would I suppose largely mitigate the issue with linking object files 
made from raw data with LD or `objcopy'.

  Maciej
  

Let's be back to the problem of this patch: what should we do for
     mipsisa32rXel-*-as -64
and
    mipsisa64rXel-*-as -32
We have several options:
1. Keep current, aka issue an error message and exit for 32-64 combination.
2. set the default arch to mips64r6 only for mipsisa32r6, aka not for
mipsisa32r[1-5].
    set the default arch to mips32r6 only for mipsisa64r6, aka not for
mipsisa32r[1-5].
    That's what I did in this patch.
3. set the default arch to mips64rN for mipsisa32rN
    set the default arch to mips32rN for mipsisa64rN
    but do nothing for any other triples, such as
       mipstx39* or mips64vr,
    Since it's hard to determine which arches are best for them.
4. Set the default 32/64 arch for all triples.
  

YunQiang Su <syq@debian.org> writes:
> Let's be back to the problem of this patch: what should we do for
>      mipsisa32rXel-*-as -64
> and
>     mipsisa64rXel-*-as -32
> We have several options:
> 1. Keep current, aka issue an error message and exit for 32-64 combination.
> 2. set the default arch to mips64r6 only for mipsisa32r6, aka not for
> mipsisa32r[1-5].
>     set the default arch to mips32r6 only for mipsisa64r6, aka not for
> mipsisa32r[1-5].
>     That's what I did in this patch.
> 3. set the default arch to mips64rN for mipsisa32rN
>     set the default arch to mips32rN for mipsisa64rN
>     but do nothing for any other triples, such as
>        mipstx39* or mips64vr,
>     Since it's hard to determine which arches are best for them.

Personally, I think we should do this one, similarly to your
9171de358f230b64646bbb525a74e5f8e3dbe0dc.  IMO it's better to think
of mipsr6+ as a separate ISA group from pre-r6, since no pair of ISAs
from either group is binary compatible in either direction.

So for mipsr6+ toolchains (those with a mipsr6+ triplet), from-abi
should select the appropriate r6 ISA rather than mips1 or mips3.

Thanks,
Richard

> 4. Set the default 32/64 arch for all triples.