[v4,1/2] MIPS: support mips*64 as CPU and gnuabi64 as ABI
Checks
Commit Message
For MIPS64r6 ports, Debian as an example, `mipsisa64r6el` is
used as the cpu name in triple.
Let's recognize them by `mips*64*(el)`.
For 64bit Ports, like Debian's mips64el and mips64r6el ports,
`gnuabi64` is used as the abi section.
Let's use N64 abi by default for the triple with gnuabi64.
---
bfd/config.bfd | 14 ++++++++++++--
.../testsuite/binutils-all/mips/mips-note-2-n32.d | 1 +
gas/configure | 5 ++++-
gas/configure.ac | 5 ++++-
gold/configure.tgt | 14 ++++++++++++++
ld/configure.tgt | 12 ++++++++++--
6 files changed, 45 insertions(+), 6 deletions(-)
Comments
YunQiang Su <yunqiang.su@cipunited.com> writes:
> For MIPS64r6 ports, Debian as an example, `mipsisa64r6el` is
> used as the cpu name in triple.
> Let's recognize them by `mips*64*(el)`.
>
> For 64bit Ports, like Debian's mips64el and mips64r6el ports,
> `gnuabi64` is used as the abi section.
> Let's use N64 abi by default for the triple with gnuabi64.
> ---
> bfd/config.bfd | 14 ++++++++++++--
> .../testsuite/binutils-all/mips/mips-note-2-n32.d | 1 +
> gas/configure | 5 ++++-
> gas/configure.ac | 5 ++++-
> gold/configure.tgt | 14 ++++++++++++++
> ld/configure.tgt | 12 ++++++++++--
> 6 files changed, 45 insertions(+), 6 deletions(-)
OK, thanks.
Please send a message to admin-requests@ to extend your write access
to binutils-gdb (cc:ing me).
Richard
> diff --git a/bfd/config.bfd b/bfd/config.bfd
> index 7af481048db..1e4bea191dd 100644
> --- a/bfd/config.bfd
> +++ b/bfd/config.bfd
> @@ -941,11 +941,21 @@ case "${targ}" in
> targ_defvec=mips_elf32_be_vec
> targ_selvecs="mips_elf32_le_vec mips_elf64_be_vec mips_elf64_le_vec mips_ecoff_be_vec mips_ecoff_le_vec"
> ;;
> - mips64*el-*-linux*)
> + mips*64*el-*-linux*-gnuabi64)
> + targ_defvec=mips_elf64_trad_le_vec
> + targ_selvecs="mips_elf32_ntrad_be_vec mips_elf32_ntrad_le_vec mips_elf32_trad_be_vec mips_elf32_trad_le_vec mips_elf64_trad_be_vec"
> + want64=true
> + ;;
> + mips*64*-*-linux*-gnuabi64)
> + targ_defvec=mips_elf64_trad_be_vec
> + targ_selvecs="mips_elf32_ntrad_be_vec mips_elf32_ntrad_le_vec mips_elf32_trad_be_vec mips_elf32_trad_le_vec mips_elf64_trad_le_vec"
> + want64=true
> + ;;
> + mips*64*el-*-linux*)
> targ_defvec=mips_elf32_ntrad_le_vec
> targ_selvecs="mips_elf32_ntrad_be_vec mips_elf32_trad_le_vec mips_elf32_trad_be_vec mips_elf64_trad_le_vec mips_elf64_trad_be_vec"
> ;;
> - mips64*-*-linux*)
> + mips*64*-*-linux*)
> targ_defvec=mips_elf32_ntrad_be_vec
> targ_selvecs="mips_elf32_ntrad_le_vec mips_elf32_trad_be_vec mips_elf32_trad_le_vec mips_elf64_trad_be_vec mips_elf64_trad_le_vec"
> ;;
> diff --git a/binutils/testsuite/binutils-all/mips/mips-note-2-n32.d b/binutils/testsuite/binutils-all/mips/mips-note-2-n32.d
> index c2a581858ed..5e24e7a115e 100644
> --- a/binutils/testsuite/binutils-all/mips/mips-note-2-n32.d
> +++ b/binutils/testsuite/binutils-all/mips/mips-note-2-n32.d
> @@ -1,4 +1,5 @@
> #PROG: objcopy
> +#as: -n32
> #readelf: --notes --wide
> #objcopy: --merge-notes
> #name: MIPS merge notes section (n32)
> diff --git a/gas/configure b/gas/configure
> index b56836998ef..868f4a911a9 100755
> --- a/gas/configure
> +++ b/gas/configure
> @@ -12223,7 +12223,10 @@ _ACEOF
> esac
> # Decide which ABI to target by default.
> case ${target} in
> - mips64*-linux* | mips-sgi-irix6* | mips64*-freebsd* \
> + mips*64*-linux-gnuabi64)
> + mips_default_abi=N64_ABI
> + ;;
> + mips*64*-linux* | mips-sgi-irix6* | mips64*-freebsd* \
> | mips64*-kfreebsd*-gnu | mips64*-ps2-elf*)
> mips_default_abi=N32_ABI
> ;;
> diff --git a/gas/configure.ac b/gas/configure.ac
> index 6a68fd7c4e6..03728ffce4d 100644
> --- a/gas/configure.ac
> +++ b/gas/configure.ac
> @@ -392,7 +392,10 @@ changequote([,])dnl
> esac
> # Decide which ABI to target by default.
> case ${target} in
> - mips64*-linux* | mips-sgi-irix6* | mips64*-freebsd* \
> + mips*64*-linux-gnuabi64)
> + mips_default_abi=N64_ABI
> + ;;
> + mips*64*-linux* | mips-sgi-irix6* | mips64*-freebsd* \
> | mips64*-kfreebsd*-gnu | mips64*-ps2-elf*)
> mips_default_abi=N32_ABI
> ;;
> diff --git a/gold/configure.tgt b/gold/configure.tgt
> index 4b54e08d27f..ef47ce079f1 100644
> --- a/gold/configure.tgt
> +++ b/gold/configure.tgt
> @@ -153,6 +153,13 @@ aarch64*-*)
> targ_big_endian=false
> targ_extra_big_endian=true
> ;;
> +mips*64*el*-*-*|mips*64*le*-*-*)
> + targ_obj=mips
> + targ_machine=EM_MIPS_RS3_LE
> + targ_size=64
> + targ_big_endian=false
> + targ_extra_big_endian=true
> + ;;
> mips*el*-*-*|mips*le*-*-*)
> targ_obj=mips
> targ_machine=EM_MIPS_RS3_LE
> @@ -160,6 +167,13 @@ mips*el*-*-*|mips*le*-*-*)
> targ_big_endian=false
> targ_extra_big_endian=true
> ;;
> +mips*64*-*-*)
> + targ_obj=mips
> + targ_machine=EM_MIPS
> + targ_size=64
> + targ_big_endian=true
> + targ_extra_big_endian=false
> + ;;
> mips*-*-*)
> targ_obj=mips
> targ_machine=EM_MIPS
> diff --git a/ld/configure.tgt b/ld/configure.tgt
> index 34c9d67c365..4a71f679e29 100644
> --- a/ld/configure.tgt
> +++ b/ld/configure.tgt
> @@ -580,11 +580,19 @@ mips*-*-vxworks*) targ_emul=elf32ebmipvxworks
> ;;
> mips*-*-windiss) targ_emul=elf32mipswindiss
> ;;
> -mips64*el-*-linux-*) targ_emul=elf32ltsmipn32
> +mips*64*el-*-linux-gnuabi64) targ_emul=elf64ltsmip
> + targ_extra_emuls="elf32btsmipn32 elf32ltsmipn32 elf32ltsmip elf32btsmip elf64btsmip"
> + targ_extra_libpath=$targ_extra_emuls
> + ;;
> +mips*64*el-*-linux-*) targ_emul=elf32ltsmipn32
> targ_extra_emuls="elf32btsmipn32 elf32ltsmip elf32btsmip elf64ltsmip elf64btsmip"
> targ_extra_libpath=$targ_extra_emuls
> ;;
> -mips64*-*-linux-*) targ_emul=elf32btsmipn32
> +mips*64*-*-linux-gnuabi64) targ_emul=elf64btsmip
> + targ_extra_emuls="elf32btsmipn32 elf32ltsmipn32 elf32btsmip elf32ltsmip elf64ltsmip"
> + targ_extra_libpath=$targ_extra_emuls
> + ;;
> +mips*64*-*-linux-*) targ_emul=elf32btsmipn32
> targ_extra_emuls="elf32ltsmipn32 elf32btsmip elf32ltsmip elf64btsmip elf64ltsmip"
> targ_extra_libpath=$targ_extra_emuls
> ;;
Nick, please hold on with 2.41 until this incompatible ABI change has been
sorted.
On Wed, 19 Apr 2023, Richard Sandiford wrote:
> > For MIPS64r6 ports, Debian as an example, `mipsisa64r6el` is
> > used as the cpu name in triple.
> > Let's recognize them by `mips*64*(el)`.
> >
> > For 64bit Ports, like Debian's mips64el and mips64r6el ports,
> > `gnuabi64` is used as the abi section.
> > Let's use N64 abi by default for the triple with gnuabi64.
> > ---
> > bfd/config.bfd | 14 ++++++++++++--
> > .../testsuite/binutils-all/mips/mips-note-2-n32.d | 1 +
> > gas/configure | 5 ++++-
> > gas/configure.ac | 5 ++++-
> > gold/configure.tgt | 14 ++++++++++++++
> > ld/configure.tgt | 12 ++++++++++--
> > 6 files changed, 45 insertions(+), 6 deletions(-)
>
> OK, thanks.
So this has changed the default ABI from o32 to n32 for `mipsisa64-*-*'
targets and the like, which I only realised by getting odd results from an
attempt to make a test case for another change of YunQiang's I have begun
reviewing now.
I can't find this rather significant and incompatible change of semantics
mentioned anywhere in the trail of messages associated with this patch
submission, let alone the change description. Have you been aware of it
and acked the change regardless, or has it slipped through?
It seems to me such a major change, even if actually approved, should be
rather prominently mentioned in the change description with rationale
given, and made on its own rather than with other modifications.
NB I'm stuck with the other review until this has been sorted and may
have to revert this change too, as I have the other change ready to commit
except for conflicting test results. Also we need to be careful not to
let this get downstream with 2.41 unless we're very, very sure it is the
right change to make.
Maciej
Maciej W. Rozycki <macro@orcam.me.uk> 于2023年7月21日周五 18:01写道：
>
> Nick, please hold on with 2.41 until this incompatible ABI change has been
> sorted.
>
> On Wed, 19 Apr 2023, Richard Sandiford wrote:
>
> > > For MIPS64r6 ports, Debian as an example, `mipsisa64r6el` is
> > > used as the cpu name in triple.
> > > Let's recognize them by `mips*64*(el)`.
> > >
> > > For 64bit Ports, like Debian's mips64el and mips64r6el ports,
> > > `gnuabi64` is used as the abi section.
> > > Let's use N64 abi by default for the triple with gnuabi64.
> > > ---
> > > bfd/config.bfd | 14 ++++++++++++--
> > > .../testsuite/binutils-all/mips/mips-note-2-n32.d | 1 +
> > > gas/configure | 5 ++++-
> > > gas/configure.ac | 5 ++++-
> > > gold/configure.tgt | 14 ++++++++++++++
> > > ld/configure.tgt | 12 ++++++++++--
> > > 6 files changed, 45 insertions(+), 6 deletions(-)
> >
> > OK, thanks.
>
> So this has changed the default ABI from o32 to n32 for `mipsisa64-*-*'
I think that maybe you have a misunderstanding.
1. It is *not* for `mipsisa64-*-*', it is for `mipsisa64-*-gnuabi64'
2. It is not from O32 to N32. It is from N32 to N64.
> targets and the like, which I only realised by getting odd results from an
> attempt to make a test case for another change of YunQiang's I have begun
> reviewing now.
>
> I can't find this rather significant and incompatible change of semantics
> mentioned anywhere in the trail of messages associated with this patch
> submission, let alone the change description. Have you been aware of it
> and acked the change regardless, or has it slipped through?
>
> It seems to me such a major change, even if actually approved, should be
> rather prominently mentioned in the change description with rationale
> given, and made on its own rather than with other modifications.
>
> NB I'm stuck with the other review until this has been sorted and may
> have to revert this change too, as I have the other change ready to commit
> except for conflicting test results. Also we need to be careful not to
> let this get downstream with 2.41 unless we're very, very sure it is the
> right change to make.
>
> Maciej
On Fri, 21 Jul 2023, YunQiang Su wrote:
> Maciej W. Rozycki <macro@orcam.me.uk> 于2023年7月21日周五 18:01写道：
> >
> > Nick, please hold on with 2.41 until this incompatible ABI change has been
> > sorted.
> >
> > On Wed, 19 Apr 2023, Richard Sandiford wrote:
> >
> > > > For MIPS64r6 ports, Debian as an example, `mipsisa64r6el` is
> > > > used as the cpu name in triple.
> > > > Let's recognize them by `mips*64*(el)`.
> > > >
> > > > For 64bit Ports, like Debian's mips64el and mips64r6el ports,
> > > > `gnuabi64` is used as the abi section.
> > > > Let's use N64 abi by default for the triple with gnuabi64.
> > > > ---
> > > > bfd/config.bfd | 14 ++++++++++++--
> > > > .../testsuite/binutils-all/mips/mips-note-2-n32.d | 1 +
> > > > gas/configure | 5 ++++-
> > > > gas/configure.ac | 5 ++++-
> > > > gold/configure.tgt | 14 ++++++++++++++
> > > > ld/configure.tgt | 12 ++++++++++--
> > > > 6 files changed, 45 insertions(+), 6 deletions(-)
> > >
> > > OK, thanks.
> >
> > So this has changed the default ABI from o32 to n32 for `mipsisa64-*-*'
>
> I think that maybe you have a misunderstanding.
> 1. It is *not* for `mipsisa64-*-*', it is for `mipsisa64-*-gnuabi64'
> 2. It is not from O32 to N32. It is from N32 to N64.
Well test results say otherwise. Please build yourself binutils for
`mipsisa64-linux' and see what output format it uses with and without this
change.
I have:
$ mipsisa64-linux/gas/as-new /dev/null -o null.o
$ file null.o
null.o: ELF 32-bit MSB relocatable, MIPS, MIPS64 version 1 (SYSV), not stripped
$ mipsisa64-linux/ld/ld-new -e 0 null.o -o null
$ file null
null: ELF 32-bit MSB executable, MIPS, MIPS64 version 1 (SYSV), statically linked, not stripped
$
as at commit 32f1c80375eb^, and:
$ mipsisa64-linux/gas/as-new /dev/null -o null.o
$ file null.o
null.o: ELF 32-bit MSB relocatable, MIPS, MIPS64 version 1 (SYSV), not stripped
$ mipsisa64-linux/ld/ld-new -e 0 null.o -o null
mipsisa64-linux/ld/ld-new: null.o: ABI is incompatible with that of the selected emulation
mipsisa64-linux/ld/ld-new: failed to merge target specific data of file null.o
$
as from commit 32f1c80375eb. The default format used by LD is now not the
same as one produced by GAS.
Maciej
Maciej W. Rozycki <macro@orcam.me.uk> 于2023年7月21日周五 19:54写道：
>
> On Fri, 21 Jul 2023, YunQiang Su wrote:
>
> > Maciej W. Rozycki <macro@orcam.me.uk> 于2023年7月21日周五 18:01写道：
> > >
> > > Nick, please hold on with 2.41 until this incompatible ABI change has been
> > > sorted.
> > >
> > > On Wed, 19 Apr 2023, Richard Sandiford wrote:
> > >
> > > > > For MIPS64r6 ports, Debian as an example, `mipsisa64r6el` is
> > > > > used as the cpu name in triple.
> > > > > Let's recognize them by `mips*64*(el)`.
> > > > >
> > > > > For 64bit Ports, like Debian's mips64el and mips64r6el ports,
> > > > > `gnuabi64` is used as the abi section.
> > > > > Let's use N64 abi by default for the triple with gnuabi64.
> > > > > ---
> > > > > bfd/config.bfd | 14 ++++++++++++--
> > > > > .../testsuite/binutils-all/mips/mips-note-2-n32.d | 1 +
> > > > > gas/configure | 5 ++++-
> > > > > gas/configure.ac | 5 ++++-
> > > > > gold/configure.tgt | 14 ++++++++++++++
> > > > > ld/configure.tgt | 12 ++++++++++--
> > > > > 6 files changed, 45 insertions(+), 6 deletions(-)
> > > >
> > > > OK, thanks.
> > >
> > > So this has changed the default ABI from o32 to n32 for `mipsisa64-*-*'
> >
> > I think that maybe you have a misunderstanding.
> > 1. It is *not* for `mipsisa64-*-*', it is for `mipsisa64-*-gnuabi64'
> > 2. It is not from O32 to N32. It is from N32 to N64.
>
> Well test results say otherwise. Please build yourself binutils for
> `mipsisa64-linux' and see what output format it uses with and without this
> change.
>
Ohh you are right, while, does mips*-linux without ABI section really matter?
I never hear about it is used for any real system.
> I have:
>
> $ mipsisa64-linux/gas/as-new /dev/null -o null.o
> $ file null.o
> null.o: ELF 32-bit MSB relocatable, MIPS, MIPS64 version 1 (SYSV), not stripped
I cannot reproduce it. My test result is:
null.o: ELF 32-bit MSB relocatable, MIPS, N32 MIPS64 version 1 (SYSV),
not stripped
^^
> $ mipsisa64-linux/ld/ld-new -e 0 null.o -o null
> $ file null
> null: ELF 32-bit MSB executable, MIPS, MIPS64 version 1 (SYSV), statically linked, not stripped
> $
>
> as at commit 32f1c80375eb^, and:
>
> $ mipsisa64-linux/gas/as-new /dev/null -o null.o
> $ file null.o
> null.o: ELF 32-bit MSB relocatable, MIPS, MIPS64 version 1 (SYSV), not stripped
> $ mipsisa64-linux/ld/ld-new -e 0 null.o -o null
> mipsisa64-linux/ld/ld-new: null.o: ABI is incompatible with that of the selected emulation
> mipsisa64-linux/ld/ld-new: failed to merge target specific data of file null.o
> $
>
> as from commit 32f1c80375eb. The default format used by LD is now not the
> same as one produced by GAS.
>
Yes. we should keep them sync. Since it has CPU `mipsisa64*`, so, I
think that we should
use N32 or N64.
Ohh, yes, my patch switch the default output of mips*isa64-linux to
N32 from O32.
I believe that it is an correct modification.
> Maciej
On Fri, 21 Jul 2023, YunQiang Su wrote:
> > > > So this has changed the default ABI from o32 to n32 for `mipsisa64-*-*'
> > >
> > > I think that maybe you have a misunderstanding.
> > > 1. It is *not* for `mipsisa64-*-*', it is for `mipsisa64-*-gnuabi64'
> > > 2. It is not from O32 to N32. It is from N32 to N64.
> >
> > Well test results say otherwise. Please build yourself binutils for
> > `mipsisa64-linux' and see what output format it uses with and without this
> > change.
>
> Ohh you are right, while, does mips*-linux without ABI section really matter?
> I never hear about it is used for any real system.
You may not have heard about it, but someone has added these machine
specifiers for a reason and I reckon seeing at least `mipsisa64-*-*' ones
used at one point, maybe at MTI back in ~2005. Here the "isa64" suffix
only specifies the ISA level (just as with "isa32", etc.) and not the ABI
such as with the "64" suffix.
It may have even been before we had NewABI support in the first place, so
the semantics for `mipsisa64-*-*' had to stay for backwards compatibility
already back then. And I do remember the days and the issues around
merging NewABI stuff; if MTI weren't so slow with defining it, we could
have ended up with NUBI instead rather than this old IRIX stuff, not
necessarily adequate for embedded use and with its sole advantage that it
was already well-defined then, so the community took lead and merged
NewABI support behind MTI's back.
> Ohh, yes, my patch switch the default output of mips*isa64-linux to
> N32 from O32.
> I believe that it is an correct modification.
Maybe, but this is changing what we've had for 20+ years, so it must not
be done without proper consideration, documentation, and likely a NEWS
entry, as this is a user-visible change of semantics. You can't just
decide unilaterally, especially on something that's been out there for
such a long time.
I think this close to 2.41 release the best course of action may be
reverting the change after all on trunk/2.41, and then re-applying the
uncontroversial part on trunk only. This will prevent Nick from being
held with the release and we can decide what to do with the rest. It
would unblock me with accepting your outstanding bug fix as well, also for
2.41.
And I wonder if there's more that needs to be undone for 2.41, so that it
can be then handled properly with 2.42, especially given the large
quantity of regressions introduced, which may not necessarily be solely
due to the lack of update to the testsuite and could be a sign of actual
problems introduced with the tools themselves. I'd prefer to have
results with 2.41 that are no worse than as at 32f1c80375eb^ TBH.
Maciej
Debian, as a *REAL* OS, instead of anything you are imagining, is *USING* it.
I don't agree that you make any "features" heavenly.
If so, we cannot fix any bug.
More and more software in the *REAL* world, use the CPU section (here mipsisa64)
to determine the 64bit OS/env.
Anyway, the *REAL* world is much more important the the world only in
your *MIND*.
Maciej W. Rozycki <macro@orcam.me.uk> 于2023年7月21日周五 22:31写道：
>
> On Fri, 21 Jul 2023, YunQiang Su wrote:
>
> > > > > So this has changed the default ABI from o32 to n32 for `mipsisa64-*-*'
> > > >
> > > > I think that maybe you have a misunderstanding.
> > > > 1. It is *not* for `mipsisa64-*-*', it is for `mipsisa64-*-gnuabi64'
> > > > 2. It is not from O32 to N32. It is from N32 to N64.
> > >
> > > Well test results say otherwise. Please build yourself binutils for
> > > `mipsisa64-linux' and see what output format it uses with and without this
> > > change.
> >
> > Ohh you are right, while, does mips*-linux without ABI section really matter?
> > I never hear about it is used for any real system.
>
> You may not have heard about it, but someone has added these machine
> specifiers for a reason and I reckon seeing at least `mipsisa64-*-*' ones
> used at one point, maybe at MTI back in ~2005. Here the "isa64" suffix
> only specifies the ISA level (just as with "isa32", etc.) and not the ABI
> such as with the "64" suffix.
>
> It may have even been before we had NewABI support in the first place, so
> the semantics for `mipsisa64-*-*' had to stay for backwards compatibility
> already back then. And I do remember the days and the issues around
> merging NewABI stuff; if MTI weren't so slow with defining it, we could
> have ended up with NUBI instead rather than this old IRIX stuff, not
> necessarily adequate for embedded use and with its sole advantage that it
> was already well-defined then, so the community took lead and merged
> NewABI support behind MTI's back.
>
> > Ohh, yes, my patch switch the default output of mips*isa64-linux to
> > N32 from O32.
> > I believe that it is an correct modification.
>
> Maybe, but this is changing what we've had for 20+ years, so it must not
> be done without proper consideration, documentation, and likely a NEWS
> entry, as this is a user-visible change of semantics. You can't just
> decide unilaterally, especially on something that's been out there for
> such a long time.
>
> I think this close to 2.41 release the best course of action may be
> reverting the change after all on trunk/2.41, and then re-applying the
> uncontroversial part on trunk only. This will prevent Nick from being
> held with the release and we can decide what to do with the rest. It
> would unblock me with accepting your outstanding bug fix as well, also for
> 2.41.
>
> And I wonder if there's more that needs to be undone for 2.41, so that it
> can be then handled properly with 2.42, especially given the large
> quantity of regressions introduced, which may not necessarily be solely
> due to the lack of update to the testsuite and could be a sign of actual
> problems introduced with the tools themselves. I'd prefer to have
> results with 2.41 that are no worse than as at 32f1c80375eb^ TBH.
>
> Maciej
On Fri, 2023-07-21 at 23:01 +0800, YunQiang Su wrote:
> Debian, as a *REAL* OS, instead of anything you are imagining, is *USING* it.
> I don't agree that you make any "features" heavenly.
> If so, we cannot fix any bug.
>
> More and more software in the *REAL* world, use the CPU section (here mipsisa64)
> to determine the 64bit OS/env.
> Anyway, the *REAL* world is much more important the the world only in
> your *MIND*.
I'm not sure about this debate (I've stopped development of Linux From
Scratch on MIPS64 because I don't have a good hardware now and I don't
like developing something purely on an emulator). But as a LFS editor:
please make an end to this instead of delaying the release indefinitely.
The delay will impact our plans for testing and releasing LFS 12.0.
I'm pulling Andreas (as Gentoo MIPS maintainer and the RM of the
upcoming Glibc release) into the discussion.
> Maciej W. Rozycki <macro@orcam.me.uk> 于2023年7月21日周五 22:31写道：
> >
> > On Fri, 21 Jul 2023, YunQiang Su wrote:
> >
> > > > > > So this has changed the default ABI from o32 to n32 for `mipsisa64-*-*'
> > > > >
> > > > > I think that maybe you have a misunderstanding.
> > > > > 1. It is *not* for `mipsisa64-*-*', it is for `mipsisa64-*-gnuabi64'
> > > > > 2. It is not from O32 to N32. It is from N32 to N64.
> > > >
> > > > Well test results say otherwise. Please build yourself binutils for
> > > > `mipsisa64-linux' and see what output format it uses with and without this
> > > > change.
> > >
> > > Ohh you are right, while, does mips*-linux without ABI section really matter?
> > > I never hear about it is used for any real system.
> >
> > You may not have heard about it, but someone has added these machine
> > specifiers for a reason and I reckon seeing at least `mipsisa64-*-*' ones
> > used at one point, maybe at MTI back in ~2005. Here the "isa64" suffix
> > only specifies the ISA level (just as with "isa32", etc.) and not the ABI
> > such as with the "64" suffix.
> >
> > It may have even been before we had NewABI support in the first place, so
> > the semantics for `mipsisa64-*-*' had to stay for backwards compatibility
> > already back then. And I do remember the days and the issues around
> > merging NewABI stuff; if MTI weren't so slow with defining it, we could
> > have ended up with NUBI instead rather than this old IRIX stuff, not
> > necessarily adequate for embedded use and with its sole advantage that it
> > was already well-defined then, so the community took lead and merged
> > NewABI support behind MTI's back.
> >
> > > Ohh, yes, my patch switch the default output of mips*isa64-linux to
> > > N32 from O32.
> > > I believe that it is an correct modification.
> >
> > Maybe, but this is changing what we've had for 20+ years, so it must not
> > be done without proper consideration, documentation, and likely a NEWS
> > entry, as this is a user-visible change of semantics. You can't just
> > decide unilaterally, especially on something that's been out there for
> > such a long time.
> >
> > I think this close to 2.41 release the best course of action may be
> > reverting the change after all on trunk/2.41, and then re-applying the
> > uncontroversial part on trunk only. This will prevent Nick from being
> > held with the release and we can decide what to do with the rest. It
> > would unblock me with accepting your outstanding bug fix as well, also for
> > 2.41.
> >
> > And I wonder if there's more that needs to be undone for 2.41, so that it
> > can be then handled properly with 2.42, especially given the large
> > quantity of regressions introduced, which may not necessarily be solely
> > due to the lack of update to the testsuite and could be a sign of actual
> > problems introduced with the tools themselves. I'd prefer to have
> > results with 2.41 that are no worse than as at 32f1c80375eb^ TBH.
> >
> > Maciej
Hi Guys,
Do we have a conclusion on this issue ?
If time is still needed for debate then can we at least make sure that the 2.41
branch does not have any regressions when compared to the 2.40 branch ?
I would really like to create the 2.41 release at some point in the next few
days, so fixing/isolating this problem is a priority.
Cheers
Nick
Nick Clifton <nickc@redhat.com> 于2023年7月25日周二 21:30写道：
>
> Hi Guys,
>
> Do we have a conclusion on this issue ?
>
I have no idea about Maciej.
> If time is still needed for debate then can we at least make sure that the 2.41
> branch does not have any regressions when compared to the 2.40 branch ?
>
For me, I don't think that it is a regression, instead it is a bugfix.
> I would really like to create the 2.41 release at some point in the next few
> days, so fixing/isolating this problem is a priority.
>
> Cheers
> Nick
>
>
On Tue, 25 Jul 2023, Nick Clifton wrote:
> Do we have a conclusion on this issue ?
>
> If time is still needed for debate then can we at least make sure that the
> 2.41
> branch does not have any regressions when compared to the 2.40 branch ?
>
> I would really like to create the 2.41 release at some point in the next few
> days, so fixing/isolating this problem is a priority.
For the last couple of days I have been working on a patch set, mostly
for the testsuite, to resolve the outstanding issues. I still have some
work to complete as a test case is playing tricks with me and I actually
need to run it under GDB to understand what is going on there, but I do
hope to have finished by the end of today, or tomorrow the latest.
Apologies for causing this delay, but I only realised last Friday what
had happened here.
Maciej
Am Freitag, 21. Juli 2023, 14:30:04 CEST schrieb YunQiang Su:
>
> Ohh you are right, while, does mips*-linux without ABI section really matter?
> I never hear about it is used for any real system.
>
Every current Gentoo installation.
> > Ohh you are right, while, does mips*-linux without ABI section really matter?
> > I never hear about it is used for any real system.
>
> You may not have heard about it, but someone has added these machine
> specifiers for a reason and I reckon seeing at least `mipsisa64-*-*' ones
> used at one point, maybe at MTI back in ~2005. Here the "isa64" suffix
> only specifies the ISA level (just as with "isa32", etc.) and not the ABI
> such as with the "64" suffix.
OK so right now (restricting myself to BE)
* pure 32bit system in Gentoo uses plain mips-unknown-linux-gnu
* anything 64bit (including n32) uses mips64-unknown-linux-gnu
We, Gentoo, plan to move
* n32 to mips64-unknown-linux-gnuabin32 and
* n64 to mips64-unknown-linux-gnuabi64
but so far this is just a (though already far-developed) plan.
(Also, I'm not really the main Gentoo mips expert to talk to...)
Maciej, I saw you commits, and thanks for your work.
I still have another concern: we need a mips64r6 default triples to support.
Currently, in my previous patch, I add a "*" between mips and 64, aka
mips*64*el-linux-gnu(abi64).
If you have concern about some cases, maybe we can define it only for
mips*32*-linux-gnu
mips*64*-linux-gnuabin32
mips*64*-linux-gnuabi64
Andreas K. Huettel <dilfridge@gentoo.org> 于2023年7月26日周三 01:48写道：
>
> > > Ohh you are right, while, does mips*-linux without ABI section really matter?
> > > I never hear about it is used for any real system.
> >
> > You may not have heard about it, but someone has added these machine
> > specifiers for a reason and I reckon seeing at least `mipsisa64-*-*' ones
> > used at one point, maybe at MTI back in ~2005. Here the "isa64" suffix
> > only specifies the ISA level (just as with "isa32", etc.) and not the ABI
> > such as with the "64" suffix.
>
> OK so right now (restricting myself to BE)
>
> * pure 32bit system in Gentoo uses plain mips-unknown-linux-gnu
> * anything 64bit (including n32) uses mips64-unknown-linux-gnu
>
> We, Gentoo, plan to move
> * n32 to mips64-unknown-linux-gnuabin32 and
> * n64 to mips64-unknown-linux-gnuabi64
>
> but so far this is just a (though already far-developed) plan.
>
> (Also, I'm not really the main Gentoo mips expert to talk to...)
>
> --
> Andreas K. Hüttel
> dilfridge@gentoo.org
> Gentoo Linux developer
> (council, toolchain, base-system, perl, libreoffice)
On Fri, 21 Jul 2023, YunQiang Su wrote:
> Debian, as a *REAL* OS, instead of anything you are imagining, is *USING* it.
> I don't agree that you make any "features" heavenly.
> If so, we cannot fix any bug.
Sometimes bugs have to live forever if the removal would cause more harm
than keeping them. So we best don't introduce them in the first place.
Of course a human beeings we are all bound to make mistakes, but this is
the very reason we have come up with thorough peer reviews: to catch any
mistakes early on, before they cause actual harm. Some will escape
regardless, but we need to try hard and prevent that from happening
rather than being lax.
The use of `mipsisa64-*-*' triplets for o32 ABI configurations wasn't a
bug though, it was a design decision. Now making these triplets mean n32
after they meant something else for 20+ years seems like a bug to me.
> More and more software in the *REAL* world, use the CPU section (here mipsisa64)
> to determine the 64bit OS/env.
> Anyway, the *REAL* world is much more important the the world only in
> your *MIND*.
Personal insults are not going to help you with getting changes accepted,
as we're making decisions based on technical merits rather than opinions.
I don't think a fait accompli ("Debian does it") is a valid argument in a
technical review. It is just a statement of fact and we do not have to
accept the same solution while Debian is free to continue using it.
At the risk of repeating myself, you do need to justify your change
before it can be accepted, that is you have to provide technical arguments
to prove it to the reviewer that taking your change is the right thing to
do. You may certainly reuse the arguments that were given at the time the
choice was evaluated for Debian and if we find them convincing, we will
accept the change.
I don't think we have a document written down for submitting patches
specifically for binutils, but we have been broadly following the rules
for the GNU toolchain, as documented on pages for our sibling projects:
<https://gcc.gnu.org/contribute.html>,
<https://sourceware.org/gdb/wiki/ContributionChecklist>,
<https://sourceware.org/glibc/wiki/Contribution_checklist>.
Please familiarise yourself with these documents before posting further
changes and follow the patch submission guidelines set out there.
I'd expect you, now as a nominated MIPS GCC backend maintainer, to be
especially familiar with the first of these documents, the rules of which
you are expected not only to apply to your own changes, but to enforce
them for patches submitted by other people, whether by the general public
or your fellow employees. As far I can tell it wasn't regrettably the
case with the MIPS16e2 patchset I volunteered to properly review (having
been involved with the instruction set design and having implemented the
binutils side) and which offer was ignored.
And in any case you can do whatever you want in Debian as long as it's
within what the licence allows you to, but we do not necessarily have to
accept your changes. Ideally Debian developers would have asked us in
advance if an incompatible change they want to make locally would be
accepted, or actually would have submitted it so that it lands here first
(or is rejected, in which case they'd have a chance to find an alternative
solution).
I would have argued then you probably want `mips64isa64*-*-*' or suchlike
a triplet for your 64-bit ABI configuration, leaving `mipsisa64*-*-*' ones
for 32-bit ABI configurations (at least as far as the default choice is
concerned), as that would be consistent with our current `mips*-*-*' vs
`mips64*-*-*' naming scheme.
In that scheme for the machine part we have, in this order:
1. The base prefix: `mips'/`mips64' to tell 32-bit/64-bit configurations
apart.
2. An optional implementation specification, e.g. `vr4300', `r5900',
`isa32r2', etc., which sets the CPU default as with the `-march='
option.
3. An optional `el' endianness suffix to make the little endianness the
default rather than the big one.
So `mipstx39el-*-*' is a 32-bit configuration with the TX39 CPU chosen by
default and little endianness. Likewise `mips64r10000-*-*' is a 64-bit
big-endian one with the R10k default. Then `mipsocteon+-*-*' is a 32-bit
one with Octeon+, and for a 64-bit one then say `mips64octeon+-*-*'.
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.
We do have a couple of legacy aberrations from very old, pre-MIPS32 days,
most notably `mips-sgi-irix6', but I think there's no need to go back
there.
Of course not all configurations are valid, e.g. `mips64isa32-*-*' is
not, but neither is say `mips64tx39-*-*', so that's no news. And then
`mipsinteraptiv-mr2el-*-*' is broken due to the presence of the hyphen in
`mipsinteraptiv-mr2', which is an oversight of mine: we need to define an
`interaptiv_mr2' (or `interaptiv+mr2') alias to allow this configuration,
similarly to how say `74kf3_2' has been named, and remember not to use a
hyphen in any future CPU names.
There's really no need to break anything here, we've had it from time
immemorial.
I note however that `config.sub' hasn't been correctly updated for the
MIPS CPU names and consequently we have a random choice only that works
and other ones don't. In fact given the variability of our MIPS
configurations I fail to see why it doesn't just let it all through. I
have submitted a fix now.
Maciej
Maciej W. Rozycki <macro@orcam.me.uk> 于2023年7月31日周一 18:05写道：
>
> On Fri, 21 Jul 2023, YunQiang Su wrote:
>
> > Debian, as a *REAL* OS, instead of anything you are imagining, is *USING* it.
> > I don't agree that you make any "features" heavenly.
> > If so, we cannot fix any bug.
>
> Sometimes bugs have to live forever if the removal would cause more harm
> than keeping them. So we best don't introduce them in the first place.
> Of course a human beeings we are all bound to make mistakes, but this is
> the very reason we have come up with thorough peer reviews: to catch any
> mistakes early on, before they cause actual harm. Some will escape
> regardless, but we need to try hard and prevent that from happening
> rather than being lax.
>
> The use of `mipsisa64-*-*' triplets for o32 ABI configurations wasn't a
> bug though, it was a design decision. Now making these triplets mean n32
> after they meant something else for 20+ years seems like a bug to me.
>
> > More and more software in the *REAL* world, use the CPU section (here mipsisa64)
> > to determine the 64bit OS/env.
> > Anyway, the *REAL* world is much more important the the world only in
> > your *MIND*.
>
> Personal insults are not going to help you with getting changes accepted,
> as we're making decisions based on technical merits rather than opinions.
>
> I don't think a fait accompli ("Debian does it") is a valid argument in a
> technical review. It is just a statement of fact and we do not have to
> accept the same solution while Debian is free to continue using it.
>
> At the risk of repeating myself, you do need to justify your change
> before it can be accepted, that is you have to provide technical arguments
> to prove it to the reviewer that taking your change is the right thing to
> do. You may certainly reuse the arguments that were given at the time the
> choice was evaluated for Debian and if we find them convincing, we will
> accept the change.
>
> I don't think we have a document written down for submitting patches
> specifically for binutils, but we have been broadly following the rules
> for the GNU toolchain, as documented on pages for our sibling projects:
>
> <https://gcc.gnu.org/contribute.html>,
> <https://sourceware.org/gdb/wiki/ContributionChecklist>,
> <https://sourceware.org/glibc/wiki/Contribution_checklist>.
>
> Please familiarise yourself with these documents before posting further
> changes and follow the patch submission guidelines set out there.
>
> I'd expect you, now as a nominated MIPS GCC backend maintainer, to be
> especially familiar with the first of these documents, the rules of which
> you are expected not only to apply to your own changes, but to enforce
> them for patches submitted by other people, whether by the general public
> or your fellow employees. As far I can tell it wasn't regrettably the
> case with the MIPS16e2 patchset I volunteered to properly review (having
> been involved with the instruction set design and having implemented the
> binutils side) and which offer was ignored.
>
> And in any case you can do whatever you want in Debian as long as it's
> within what the licence allows you to, but we do not necessarily have to
> accept your changes. Ideally Debian developers would have asked us in
> advance if an incompatible change they want to make locally would be
> accepted, or actually would have submitted it so that it lands here first
> (or is rejected, in which case they'd have a chance to find an alternative
> solution).
>
> I would have argued then you probably want `mips64isa64*-*-*' or suchlike
> a triplet for your 64-bit ABI configuration, leaving `mipsisa64*-*-*' ones
> for 32-bit ABI configurations (at least as far as the default choice is
> concerned), as that would be consistent with our current `mips*-*-*' vs
> `mips64*-*-*' naming scheme.
>
> In that scheme for the machine part we have, in this order:
>
> 1. The base prefix: `mips'/`mips64' to tell 32-bit/64-bit configurations
> apart.
>
> 2. An optional implementation specification, e.g. `vr4300', `r5900',
> `isa32r2', etc., which sets the CPU default as with the `-march='
> option.
>
> 3. An optional `el' endianness suffix to make the little endianness the
> default rather than the big one.
>
> So `mipstx39el-*-*' is a 32-bit configuration with the TX39 CPU chosen by
> default and little endianness. Likewise `mips64r10000-*-*' is a 64-bit
> big-endian one with the R10k default. Then `mipsocteon+-*-*' is a 32-bit
> one with Octeon+, and for a 64-bit one then say `mips64octeon+-*-*'.
>
> 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.
> We do have a couple of legacy aberrations from very old, pre-MIPS32 days,
> most notably `mips-sgi-irix6', but I think there's no need to go back
> there.
>
> Of course not all configurations are valid, e.g. `mips64isa32-*-*' is
> not, but neither is say `mips64tx39-*-*', so that's no news. And then
> `mipsinteraptiv-mr2el-*-*' is broken due to the presence of the hyphen in
> `mipsinteraptiv-mr2', which is an oversight of mine: we need to define an
> `interaptiv_mr2' (or `interaptiv+mr2') alias to allow this configuration,
> similarly to how say `74kf3_2' has been named, and remember not to use a
> hyphen in any future CPU names.
>
> There's really no need to break anything here, we've had it from time
> immemorial.
>
> I note however that `config.sub' hasn't been correctly updated for the
> MIPS CPU names and consequently we have a random choice only that works
> and other ones don't. In fact given the variability of our MIPS
> configurations I fail to see why it doesn't just let it all through. I
> have submitted a fix now.
>
> Maciej
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
@@ -941,11 +941,21 @@ case "${targ}" in
targ_defvec=mips_elf32_be_vec
targ_selvecs="mips_elf32_le_vec mips_elf64_be_vec mips_elf64_le_vec mips_ecoff_be_vec mips_ecoff_le_vec"
;;
- mips64*el-*-linux*)
+ mips*64*el-*-linux*-gnuabi64)
+ targ_defvec=mips_elf64_trad_le_vec
+ targ_selvecs="mips_elf32_ntrad_be_vec mips_elf32_ntrad_le_vec mips_elf32_trad_be_vec mips_elf32_trad_le_vec mips_elf64_trad_be_vec"
+ want64=true
+ ;;
+ mips*64*-*-linux*-gnuabi64)
+ targ_defvec=mips_elf64_trad_be_vec
+ targ_selvecs="mips_elf32_ntrad_be_vec mips_elf32_ntrad_le_vec mips_elf32_trad_be_vec mips_elf32_trad_le_vec mips_elf64_trad_le_vec"
+ want64=true
+ ;;
+ mips*64*el-*-linux*)
targ_defvec=mips_elf32_ntrad_le_vec
targ_selvecs="mips_elf32_ntrad_be_vec mips_elf32_trad_le_vec mips_elf32_trad_be_vec mips_elf64_trad_le_vec mips_elf64_trad_be_vec"
;;
- mips64*-*-linux*)
+ mips*64*-*-linux*)
targ_defvec=mips_elf32_ntrad_be_vec
targ_selvecs="mips_elf32_ntrad_le_vec mips_elf32_trad_be_vec mips_elf32_trad_le_vec mips_elf64_trad_be_vec mips_elf64_trad_le_vec"
;;
@@ -1,4 +1,5 @@
#PROG: objcopy
+#as: -n32
#readelf: --notes --wide
#objcopy: --merge-notes
#name: MIPS merge notes section (n32)
@@ -12223,7 +12223,10 @@ _ACEOF
esac
# Decide which ABI to target by default.
case ${target} in
- mips64*-linux* | mips-sgi-irix6* | mips64*-freebsd* \
+ mips*64*-linux-gnuabi64)
+ mips_default_abi=N64_ABI
+ ;;
+ mips*64*-linux* | mips-sgi-irix6* | mips64*-freebsd* \
| mips64*-kfreebsd*-gnu | mips64*-ps2-elf*)
mips_default_abi=N32_ABI
;;
@@ -392,7 +392,10 @@ changequote([,])dnl
esac
# Decide which ABI to target by default.
case ${target} in
- mips64*-linux* | mips-sgi-irix6* | mips64*-freebsd* \
+ mips*64*-linux-gnuabi64)
+ mips_default_abi=N64_ABI
+ ;;
+ mips*64*-linux* | mips-sgi-irix6* | mips64*-freebsd* \
| mips64*-kfreebsd*-gnu | mips64*-ps2-elf*)
mips_default_abi=N32_ABI
;;
@@ -153,6 +153,13 @@ aarch64*-*)
targ_big_endian=false
targ_extra_big_endian=true
;;
+mips*64*el*-*-*|mips*64*le*-*-*)
+ targ_obj=mips
+ targ_machine=EM_MIPS_RS3_LE
+ targ_size=64
+ targ_big_endian=false
+ targ_extra_big_endian=true
+ ;;
mips*el*-*-*|mips*le*-*-*)
targ_obj=mips
targ_machine=EM_MIPS_RS3_LE
@@ -160,6 +167,13 @@ mips*el*-*-*|mips*le*-*-*)
targ_big_endian=false
targ_extra_big_endian=true
;;
+mips*64*-*-*)
+ targ_obj=mips
+ targ_machine=EM_MIPS
+ targ_size=64
+ targ_big_endian=true
+ targ_extra_big_endian=false
+ ;;
mips*-*-*)
targ_obj=mips
targ_machine=EM_MIPS
@@ -580,11 +580,19 @@ mips*-*-vxworks*) targ_emul=elf32ebmipvxworks
;;
mips*-*-windiss) targ_emul=elf32mipswindiss
;;
-mips64*el-*-linux-*) targ_emul=elf32ltsmipn32
+mips*64*el-*-linux-gnuabi64) targ_emul=elf64ltsmip
+ targ_extra_emuls="elf32btsmipn32 elf32ltsmipn32 elf32ltsmip elf32btsmip elf64btsmip"
+ targ_extra_libpath=$targ_extra_emuls
+ ;;
+mips*64*el-*-linux-*) targ_emul=elf32ltsmipn32
targ_extra_emuls="elf32btsmipn32 elf32ltsmip elf32btsmip elf64ltsmip elf64btsmip"
targ_extra_libpath=$targ_extra_emuls
;;
-mips64*-*-linux-*) targ_emul=elf32btsmipn32
+mips*64*-*-linux-gnuabi64) targ_emul=elf64btsmip
+ targ_extra_emuls="elf32btsmipn32 elf32ltsmipn32 elf32btsmip elf32ltsmip elf64ltsmip"
+ targ_extra_libpath=$targ_extra_emuls
+ ;;
+mips*64*-*-linux-*) targ_emul=elf32btsmipn32
targ_extra_emuls="elf32ltsmipn32 elf32btsmip elf32ltsmip elf64btsmip elf64ltsmip"
targ_extra_libpath=$targ_extra_emuls
;;