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

["Maciej W. Rozycki" <macro@orcam.me.uk>]

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