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

[YunQiang Su]

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