diff mbox series

MIPS: use arch_32/64 instead of default_mips_arch

Message ID 20230203090544.2528175-1-yunqiang.su@cipunited.com
State New
Headers
Series MIPS: use arch_32/64 instead of default_mips_arch |

Commit Message

YunQiang Su Feb. 3, 2023, 9:05 a.m. UTC 
  The value of default_mips_arch will be always used for -march by default,
no matter what value is given to -mabi.
It will produce abnormal elf file like:
 ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV)

So we use with_arch_32 and with_arch_64 instead of default_mips_arch
for all mipsisa[32,64]rN triples.

gcc/ChangeLog:
	* config.gcc: use with_arch_32 and with_arch_64 instead of
	default_mips_arch for mipsisa[32,64]rN triples.
---
 gcc/config.gcc | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

Comments

Richard Sandiford Feb. 3, 2023, 12:28 p.m. UTC | #1 
YunQiang Su <yunqiang.su@cipunited.com> writes:
> The value of default_mips_arch will be always used for -march by default,
> no matter what value is given to -mabi.
> It will produce abnormal elf file like:
>  ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV)

Is that really wrong though?  There's nothing in principle that
prevents a 64-bit ISA being used with a 32-bit ABI, even in the
object file's metadata.

> So we use with_arch_32 and with_arch_64 instead of default_mips_arch
> for all mipsisa[32,64]rN triples.

I agree there's no benefit to using a stock MIPS64rN ISA over
a stock MIPS32rN ISA with a 32-bit ABI, and the patch is only
changing those cases.  But things are different when using
(say) MIPS4 with a 32-bit ABI, or a 64-bit processor that has
proprietary extensions.

And, for example, a mips-linux-gnu toolchain would (IIRC) require
an -march as well as an -mabi in order to generate 64-bit code.
There would be no implicit selection of a new -march.

I'm not opposed to the patch.  I just think we should be clear
about the underlying principle.  If it's just that all MIPS32/64rN
toolchains should behave in the same way (like the sde and mti ones
do), then the patch looks good.  But I don't think we should create
a general principle that -mabi determines/changes/downgrades -march.

Thanks,
Richard

>
> gcc/ChangeLog:
> 	* config.gcc: use with_arch_32 and with_arch_64 instead of
> 	default_mips_arch for mipsisa[32,64]rN triples.
> ---
>  gcc/config.gcc | 21 ++++++++++++++-------
>  1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index f0958e1c959..0b6d093d847 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -2518,13 +2518,16 @@ mips*-*-linux*)				# Linux MIPS, either endian.
>  	extra_options="${extra_options} linux-android.opt"
>  	case ${target} in
>  		mipsisa32r6*)
> -			default_mips_arch=mips32r6
> +			with_arch_32="mips32r6"
> +			with_arch_64="mips64r6"
>  			;;
>  		mipsisa32r2*)
> -			default_mips_arch=mips32r2
> +			with_arch_32="mips32r2"
> +			with_arch_64="mips64r2"
>  			;;
>  		mipsisa32*)
> -			default_mips_arch=mips32
> +			with_arch_32="mips32"
> +			with_arch_64="mips64"
>  			;;
>  		mips64el-st-linux-gnu)
>  			default_mips_abi=n32
> @@ -2540,22 +2543,26 @@ mips*-*-linux*)				# Linux MIPS, either endian.
>  			;;
>  		mipsisa64r6*-*-linux-gnuabi64)
>  			default_mips_abi=64
> -			default_mips_arch=mips64r6
> +			with_arch_32="mips32r6"
> +			with_arch_64="mips64r6"
>  			enable_mips_multilibs="yes"
>  			;;
>  		mipsisa64r6*-*-linux*)
>  			default_mips_abi=n32
> -			default_mips_arch=mips64r6
> +			with_arch_32="mips32r6"
> +			with_arch_64="mips64r6"
>  			enable_mips_multilibs="yes"
>  			;;
>  		mipsisa64r2*-*-linux-gnuabi64)
>  			default_mips_abi=64
> -			default_mips_arch=mips64r2
> +			with_arch_32="mips32r2"
> +			with_arch_64="mips64r2"
>  			enable_mips_multilibs="yes"
>  			;;
>  		mipsisa64r2*-*-linux*)
>  			default_mips_abi=n32
> -			default_mips_arch=mips64r2
> +			with_arch_32="mips32r2"
> +			with_arch_64="mips64r2"
>  			enable_mips_multilibs="yes"
>  			;;
>  		mips64*-*-linux-gnuabi64 | mipsisa64*-*-linux-gnuabi64)
YunQiang Su Feb. 3, 2023, 1:23 p.m. UTC | #2 
Richard Sandiford via Gcc-patches <gcc-patches@gcc.gnu.org>
于2023年2月3日周五 20:29写道：
>
> YunQiang Su <yunqiang.su@cipunited.com> writes:
> > The value of default_mips_arch will be always used for -march by default,
> > no matter what value is given to -mabi.
> > It will produce abnormal elf file like:
> >  ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV)
>
> Is that really wrong though?  There's nothing in principle that
> prevents a 64-bit ISA being used with a 32-bit ABI, even in the
> object file's metadata.
>

To make sure that there is no misunderstanding.
The "wrong" format is
     ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV)
                                                                      ^^
and the "correct" O32 ABI file is
     ELF 32-bit LSB relocatable, MIPS, MIPS32 rel2 version 1 (SYSV)
                                                                      ^^
and the linker refuses to interlink them together.

Do you mean that the "wrong" format is quite interesting?
Yes, While this format is never used at all.

> > So we use with_arch_32 and with_arch_64 instead of default_mips_arch
> > for all mipsisa[32,64]rN triples.
>
> I agree there's no benefit to using a stock MIPS64rN ISA over
> a stock MIPS32rN ISA with a 32-bit ABI, and the patch is only
> changing those cases.  But things are different when using
> (say) MIPS4 with a 32-bit ABI, or a 64-bit processor that has
> proprietary extensions.
>
> And, for example, a mips-linux-gnu toolchain would (IIRC) require
> an -march as well as an -mabi in order to generate 64-bit code.
> There would be no implicit selection of a new -march.
>

In fact, no: if we wish to use the default march of GCC configured,
we can use -mabi=64 only.

$ mipsel-linux-gnu-gcc -mabi=64 -c xx.c && file xx.o
xx.o: ELF 64-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV),
not stripped

There does be a problem:
$ mipsel-linux-gnu-gcc -mabi=32 -march=mips64r2 -c xx.c && file xx.o
xx.o: ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV),
not stripped
                                                                         ^^
> I'm not opposed to the patch.  I just think we should be clear
> about the underlying principle.  If it's just that all MIPS32/64rN
> toolchains should behave in the same way (like the sde and mti ones
> do), then the patch looks good.  But I don't think we should create
> a general principle that -mabi determines/changes/downgrades -march.
>

In fact, I prefer what x86 does now:
$ gcc -m32 -march=haswell -c -O3 xx.c && file xx.o
xx.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped

But MIPS does like:
$ mipsel-linux-gnu-gcc -mabi=32 -march=octeon -c yy.c && file yy.o
yy.o: ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV),
not stripped
                                                                         ^^
$ mipsel-linux-gnu-gcc -mabi=32 -march=mips64r2 -c yy.c && file yy.o
yy.o: ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV),
not stripped
                                                                         ^^

I hope I can fix this problem for MIPS, although I have no idea how to
do so yet.

> Thanks,
> Richard
>
> >
> > gcc/ChangeLog:
> >       * config.gcc: use with_arch_32 and with_arch_64 instead of
> >       default_mips_arch for mipsisa[32,64]rN triples.
> > ---
> >  gcc/config.gcc | 21 ++++++++++++++-------
> >  1 file changed, 14 insertions(+), 7 deletions(-)
> >
> > diff --git a/gcc/config.gcc b/gcc/config.gcc
> > index f0958e1c959..0b6d093d847 100644
> > --- a/gcc/config.gcc
> > +++ b/gcc/config.gcc
> > @@ -2518,13 +2518,16 @@ mips*-*-linux*)                               # Linux MIPS, either endian.
> >       extra_options="${extra_options} linux-android.opt"
> >       case ${target} in
> >               mipsisa32r6*)
> > -                     default_mips_arch=mips32r6
> > +                     with_arch_32="mips32r6"
> > +                     with_arch_64="mips64r6"
> >                       ;;
> >               mipsisa32r2*)
> > -                     default_mips_arch=mips32r2
> > +                     with_arch_32="mips32r2"
> > +                     with_arch_64="mips64r2"
> >                       ;;
> >               mipsisa32*)
> > -                     default_mips_arch=mips32
> > +                     with_arch_32="mips32"
> > +                     with_arch_64="mips64"
> >                       ;;
> >               mips64el-st-linux-gnu)
> >                       default_mips_abi=n32
> > @@ -2540,22 +2543,26 @@ mips*-*-linux*)                               # Linux MIPS, either endian.
> >                       ;;
> >               mipsisa64r6*-*-linux-gnuabi64)
> >                       default_mips_abi=64
> > -                     default_mips_arch=mips64r6
> > +                     with_arch_32="mips32r6"
> > +                     with_arch_64="mips64r6"
> >                       enable_mips_multilibs="yes"
> >                       ;;
> >               mipsisa64r6*-*-linux*)
> >                       default_mips_abi=n32
> > -                     default_mips_arch=mips64r6
> > +                     with_arch_32="mips32r6"
> > +                     with_arch_64="mips64r6"
> >                       enable_mips_multilibs="yes"
> >                       ;;
> >               mipsisa64r2*-*-linux-gnuabi64)
> >                       default_mips_abi=64
> > -                     default_mips_arch=mips64r2
> > +                     with_arch_32="mips32r2"
> > +                     with_arch_64="mips64r2"
> >                       enable_mips_multilibs="yes"
> >                       ;;
> >               mipsisa64r2*-*-linux*)
> >                       default_mips_abi=n32
> > -                     default_mips_arch=mips64r2
> > +                     with_arch_32="mips32r2"
> > +                     with_arch_64="mips64r2"
> >                       enable_mips_multilibs="yes"
> >                       ;;
> >               mips64*-*-linux-gnuabi64 | mipsisa64*-*-linux-gnuabi64)
Richard Sandiford Feb. 3, 2023, 2:08 p.m. UTC | #3 
YunQiang Su <syq@debian.org> writes:
> Richard Sandiford via Gcc-patches <gcc-patches@gcc.gnu.org>
> 于2023年2月3日周五 20:29写道：
>>
>> YunQiang Su <yunqiang.su@cipunited.com> writes:
>> > The value of default_mips_arch will be always used for -march by default,
>> > no matter what value is given to -mabi.
>> > It will produce abnormal elf file like:
>> >  ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV)
>>
>> Is that really wrong though?  There's nothing in principle that
>> prevents a 64-bit ISA being used with a 32-bit ABI, even in the
>> object file's metadata.
>>
>
> To make sure that there is no misunderstanding.
> The "wrong" format is
>      ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV)
>                                                                       ^^
> and the "correct" O32 ABI file is
>      ELF 32-bit LSB relocatable, MIPS, MIPS32 rel2 version 1 (SYSV)
>                                                                       ^^
> and the linker refuses to interlink them together.
>
> Do you mean that the "wrong" format is quite interesting?
> Yes, While this format is never used at all.

My point was that there is nothing wrong in principle with creating
an o32 executable that has a 64-bit rather than a 32-bit ISA (since the
64-bit ISAs are pure extensions of 32-bit ISAs).  Doing that is even
useful in some cases.  For example, MIPS4+O32 is a useful combination,
even though MIPS4 is a 64-bit ISA.  Same for Octeon3+O32, etc.

So is the linker behaviour really correct?  Doesn't it mean that
Octeon3 O32 binaries are link-incompatible with MIPS32 o32 binaries?

>> > So we use with_arch_32 and with_arch_64 instead of default_mips_arch
>> > for all mipsisa[32,64]rN triples.
>>
>> I agree there's no benefit to using a stock MIPS64rN ISA over
>> a stock MIPS32rN ISA with a 32-bit ABI, and the patch is only
>> changing those cases.  But things are different when using
>> (say) MIPS4 with a 32-bit ABI, or a 64-bit processor that has
>> proprietary extensions.
>>
>> And, for example, a mips-linux-gnu toolchain would (IIRC) require
>> an -march as well as an -mabi in order to generate 64-bit code.
>> There would be no implicit selection of a new -march.
>>
>
> In fact, no: if we wish to use the default march of GCC configured,
> we can use -mabi=64 only.
>
> $ mipsel-linux-gnu-gcc -mabi=64 -c xx.c && file xx.o
> xx.o: ELF 64-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV),
> not stripped

Ah, OK, thanks for the correction.  I obviously misremembered.

> There does be a problem:
> $ mipsel-linux-gnu-gcc -mabi=32 -march=mips64r2 -c xx.c && file xx.o
> xx.o: ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV),
> not stripped
>                                                                          ^^
>> I'm not opposed to the patch.  I just think we should be clear
>> about the underlying principle.  If it's just that all MIPS32/64rN
>> toolchains should behave in the same way (like the sde and mti ones
>> do), then the patch looks good.  But I don't think we should create
>> a general principle that -mabi determines/changes/downgrades -march.
>>
>
> In fact, I prefer what x86 does now:
> $ gcc -m32 -march=haswell -c -O3 xx.c && file xx.o
> xx.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
>
> But MIPS does like:
> $ mipsel-linux-gnu-gcc -mabi=32 -march=octeon -c yy.c && file yy.o
> yy.o: ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV),
> not stripped
>                                                                          ^^
> $ mipsel-linux-gnu-gcc -mabi=32 -march=mips64r2 -c yy.c && file yy.o
> yy.o: ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV),
> not stripped
>                                                                          ^^
>
> I hope I can fix this problem for MIPS, although I have no idea how to
> do so yet.

The current MIPS behaviour is what I'd expect though, given the
command lines.

file doesn't tell the full story.  The ELF flags should also
distinguish between the -march=octeon and -march=mips64r2 cases.

Thanks,
Richard

>
>> Thanks,
>> Richard
>>
>> >
>> > gcc/ChangeLog:
>> >       * config.gcc: use with_arch_32 and with_arch_64 instead of
>> >       default_mips_arch for mipsisa[32,64]rN triples.
>> > ---
>> >  gcc/config.gcc | 21 ++++++++++++++-------
>> >  1 file changed, 14 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/gcc/config.gcc b/gcc/config.gcc
>> > index f0958e1c959..0b6d093d847 100644
>> > --- a/gcc/config.gcc
>> > +++ b/gcc/config.gcc
>> > @@ -2518,13 +2518,16 @@ mips*-*-linux*)                               # Linux MIPS, either endian.
>> >       extra_options="${extra_options} linux-android.opt"
>> >       case ${target} in
>> >               mipsisa32r6*)
>> > -                     default_mips_arch=mips32r6
>> > +                     with_arch_32="mips32r6"
>> > +                     with_arch_64="mips64r6"
>> >                       ;;
>> >               mipsisa32r2*)
>> > -                     default_mips_arch=mips32r2
>> > +                     with_arch_32="mips32r2"
>> > +                     with_arch_64="mips64r2"
>> >                       ;;
>> >               mipsisa32*)
>> > -                     default_mips_arch=mips32
>> > +                     with_arch_32="mips32"
>> > +                     with_arch_64="mips64"
>> >                       ;;
>> >               mips64el-st-linux-gnu)
>> >                       default_mips_abi=n32
>> > @@ -2540,22 +2543,26 @@ mips*-*-linux*)                               # Linux MIPS, either endian.
>> >                       ;;
>> >               mipsisa64r6*-*-linux-gnuabi64)
>> >                       default_mips_abi=64
>> > -                     default_mips_arch=mips64r6
>> > +                     with_arch_32="mips32r6"
>> > +                     with_arch_64="mips64r6"
>> >                       enable_mips_multilibs="yes"
>> >                       ;;
>> >               mipsisa64r6*-*-linux*)
>> >                       default_mips_abi=n32
>> > -                     default_mips_arch=mips64r6
>> > +                     with_arch_32="mips32r6"
>> > +                     with_arch_64="mips64r6"
>> >                       enable_mips_multilibs="yes"
>> >                       ;;
>> >               mipsisa64r2*-*-linux-gnuabi64)
>> >                       default_mips_abi=64
>> > -                     default_mips_arch=mips64r2
>> > +                     with_arch_32="mips32r2"
>> > +                     with_arch_64="mips64r2"
>> >                       enable_mips_multilibs="yes"
>> >                       ;;
>> >               mipsisa64r2*-*-linux*)
>> >                       default_mips_abi=n32
>> > -                     default_mips_arch=mips64r2
>> > +                     with_arch_32="mips32r2"
>> > +                     with_arch_64="mips64r2"
>> >                       enable_mips_multilibs="yes"
>> >                       ;;
>> >               mips64*-*-linux-gnuabi64 | mipsisa64*-*-linux-gnuabi64)
Xi Ruoyao Feb. 3, 2023, 2:34 p.m. UTC | #4 
On Fri, 2023-02-03 at 14:08 +0000, Richard Sandiford via Gcc-patches
wrote:
> > Do you mean that the "wrong" format is quite interesting?
> > Yes, While this format is never used at all.
> 
> My point was that there is nothing wrong in principle with creating
> an o32 executable that has a 64-bit rather than a 32-bit ISA (since
> the
> 64-bit ISAs are pure extensions of 32-bit ISAs).  Doing that is even
> useful in some cases.  For example, MIPS4+O32 is a useful combination,
> even though MIPS4 is a 64-bit ISA.  Same for Octeon3+O32, etc.
> 
> So is the linker behaviour really correct?  Doesn't it mean that
> Octeon3 O32 binaries are link-incompatible with MIPS32 o32 binaries?

On gcc230:

xry111@gcc230:~$ cat a.c
int a() { return 42; }
xry111@gcc230:~$ cat b.c
extern int a(void);
int main() { return a() ^ 42; }
xry111@gcc230:~$ cc a.c -mabi=32 -march=mips32r2 -c
xry111@gcc230:~$ cc b.c -mabi=32 -march=mips64r2 -c
xry111@gcc230:~$ cc a.o b.o
xry111@gcc230:~$ ./a.out && echo ok
ok
xry111@gcc230:~$ 
xry111@gcc230:~$ ld -version
GNU ld (GNU Binutils for Debian) 2.31.1
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

So I'd consider the issue a GNU ld regression if it suddenly stops to
behave like this.
YunQiang Su Feb. 3, 2023, 3:22 p.m. UTC | #5 
Xi Ruoyao via Gcc-patches <gcc-patches@gcc.gnu.org> 于2023年2月3日周五 22:35写道：
>
> On Fri, 2023-02-03 at 14:08 +0000, Richard Sandiford via Gcc-patches
> wrote:
> > > Do you mean that the "wrong" format is quite interesting?
> > > Yes, While this format is never used at all.
> >
> > My point was that there is nothing wrong in principle with creating
> > an o32 executable that has a 64-bit rather than a 32-bit ISA (since
> > the
> > 64-bit ISAs are pure extensions of 32-bit ISAs).  Doing that is even
> > useful in some cases.  For example, MIPS4+O32 is a useful combination,
> > even though MIPS4 is a 64-bit ISA.  Same for Octeon3+O32, etc.
> >
> > So is the linker behaviour really correct?  Doesn't it mean that
> > Octeon3 O32 binaries are link-incompatible with MIPS32 o32 binaries?
>
> On gcc230:
>
> xry111@gcc230:~$ cat a.c
> int a() { return 42; }
> xry111@gcc230:~$ cat b.c
> extern int a(void);
> int main() { return a() ^ 42; }
> xry111@gcc230:~$ cc a.c -mabi=32 -march=mips32r2 -c
> xry111@gcc230:~$ cc b.c -mabi=32 -march=mips64r2 -c
> xry111@gcc230:~$ cc a.o b.o
> xry111@gcc230:~$ ./a.out && echo ok
> ok
> xry111@gcc230:~$
> xry111@gcc230:~$ ld -version
> GNU ld (GNU Binutils for Debian) 2.31.1
> Copyright (C) 2018 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
> This program has absolutely no warranty.
>
> So I'd consider the issue a GNU ld regression if it suddenly stops to
> behave like this.

Sorry, I made a mistake: r2 works well while r6 does not.
root@bookworm-mips64r6el:~# gcc -mabi=32 -mips64r6 -O3 -c yy.c
root@bookworm-mips64r6el:~# gcc -mabi=32 -mips32r6 -O3 -c xx.c
root@bookworm-mips64r6el:~# gcc -shared -o xx.so yy.o xx.o
/usr/bin/ld: yy.o: ABI is incompatible with that of the selected emulation
/usr/bin/ld: failed to merge target specific data of file yy.o
/usr/bin/ld: xx.o: ABI is incompatible with that of the selected emulation
/usr/bin/ld: failed to merge target specific data of file xx.o
collect2: error: ld returned 1 exit status

So, it seems that I need to find what happens in gnu ld for r6.

> --
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University
diff mbox series

Patch

diff --git a/gcc/config.gcc b/gcc/config.gcc
index f0958e1c959..0b6d093d847 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2518,13 +2518,16 @@  mips*-*-linux*)				# Linux MIPS, either endian.
 	extra_options="${extra_options} linux-android.opt"
 	case ${target} in
 		mipsisa32r6*)
-			default_mips_arch=mips32r6
+			with_arch_32="mips32r6"
+			with_arch_64="mips64r6"
 			;;
 		mipsisa32r2*)
-			default_mips_arch=mips32r2
+			with_arch_32="mips32r2"
+			with_arch_64="mips64r2"
 			;;
 		mipsisa32*)
-			default_mips_arch=mips32
+			with_arch_32="mips32"
+			with_arch_64="mips64"
 			;;
 		mips64el-st-linux-gnu)
 			default_mips_abi=n32
@@ -2540,22 +2543,26 @@  mips*-*-linux*)				# Linux MIPS, either endian.
 			;;
 		mipsisa64r6*-*-linux-gnuabi64)
 			default_mips_abi=64
-			default_mips_arch=mips64r6
+			with_arch_32="mips32r6"
+			with_arch_64="mips64r6"
 			enable_mips_multilibs="yes"
 			;;
 		mipsisa64r6*-*-linux*)
 			default_mips_abi=n32
-			default_mips_arch=mips64r6
+			with_arch_32="mips32r6"
+			with_arch_64="mips64r6"
 			enable_mips_multilibs="yes"
 			;;
 		mipsisa64r2*-*-linux-gnuabi64)
 			default_mips_abi=64
-			default_mips_arch=mips64r2
+			with_arch_32="mips32r2"
+			with_arch_64="mips64r2"
 			enable_mips_multilibs="yes"
 			;;
 		mipsisa64r2*-*-linux*)
 			default_mips_abi=n32
-			default_mips_arch=mips64r2
+			with_arch_32="mips32r2"
+			with_arch_64="mips64r2"
 			enable_mips_multilibs="yes"
 			;;
 		mips64*-*-linux-gnuabi64 | mipsisa64*-*-linux-gnuabi64)