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

[YunQiang Su]

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