Re: [PATCH v4 1/2] MIPS: support mips*64 as CPU and gnuabi64 as ABI

["Maciej W. Rozycki" <macro@orcam.me.uk>]

On Mon, 31 Jul 2023, YunQiang Su wrote:

> >  Why would you want to make it different for `isa64' then?  Say
> > `mipsisa64-*-*' for a 32-bit configuration and then `mips64isa64-*-*' for
> > a 64-bit one.  In fact it already works like this: you can use
> > `mips64isa64r6-linux-gnu' and `mips64isa64r6el-linux-gnu' for your Debian
> > system right away and get what you need, there's nothing to change.
> 
> Let's go back to 10 years ago, the commit
> 5afd44e33b13b922760a41580020f941dbdd473e of GCC
> which is the previous commit of MIPS r6 support is added.
> Let's have a glance of gcc/config.gcc:
> 
> There are bellow lines:
> mips*-*-linux*)                         # Linux MIPS, either endian.
>         tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h
> glibc-stdint.h ${tm_file} mips/gnu-user.h mips/linux.h
> mips/linux-common.h"
>         extra_options="${extra_options} linux-android.opt"
>         case ${target} in
>                 mipsisa32r2*)
>                         default_mips_arch=mips32r2
>                         ;;
>                 mipsisa32*)
>                         default_mips_arch=mips32
>                         ;;
>                 mips64el-st-linux-gnu)
>                         default_mips_abi=n32
>                         tm_file="${tm_file} mips/st.h"
>                         tmake_file="${tmake_file} mips/t-st"
>                         enable_mips_multilibs="yes"
>                         ;;
>                 mips64octeon*-*-linux*)
>                         default_mips_abi=n32
>                         tm_defines="${tm_defines}
> MIPS_CPU_STRING_DEFAULT=\\\"octeon\\\""
>                         target_cpu_default=MASK_SOFT_FLOAT_ABI
>                         enable_mips_multilibs="yes"
>                         ;;
>                 mipsisa64r2*-*-linux*)
>                         default_mips_abi=n32
>                         default_mips_arch=mips64r2
>                         enable_mips_multilibs="yes"
>                         ;;
>                 mips64*-*-linux* | mipsisa64*-*-linux*)
>                         default_mips_abi=n32
>                         enable_mips_multilibs="yes"
>                         ;;
>         esac
> 
> 
> I don't think that it is a good idea that they are different between
> GCC and binutils.

 Now this I find a valid argument, which if given with the original 
submission (as a separate change from n64 though) could have prevented all 
the recent controversy.  As regrettable as I find the ABI inconsistency 
introduced to GCC with this interpretation of `mipsisa64*-*-linux*', it's 
been a part of our toolchain for long and I don't feel like it would be a 
good idea to back it out now.

 The inconsistency is worse yet AFAICS, because while `mipsisa32r2' and 
`mipsisa64r2' set the default architecture respectively to `mips32r2' and 
`mips64r2', the fallback suffixes make the random choice of `mips32' (r1) 
for `mipsisa32*' (so also e.g. for `mipsisa32r5') and nothing, presumably 
`mips3', for `mipsisa64*'.  What a mess!

 If you submit a suitably described change to synchronise this default ABI 
interpretation (but for `mipsisa64*-*-linux*' only rather than extending 
it to `mips*64*-*-linux*'), then we can start from there.  Also it's not 
commit 5afd44e33b13, which I find rather unrelated, but commit 
f2d6ca5081ba, even earlier, that added this broken interpretation of 
`mipsisa64*-*-linux*'.

 NB please trim your replies and quote the relevant parts only to save the 
reader's bandwidth.

  Maciej