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

[Xi Ruoyao]

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

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