public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Xi Ruoyao <xry111@xry111.site>
To: YunQiang Su <syq@debian.org>,
	"Maciej W. Rozycki" <macro@orcam.me.uk>,
	 "Andreas K. Huettel" <dilfridge@gentoo.org>
Cc: Richard Sandiford <richard.sandiford@arm.com>,
	Nick Clifton <nickc@redhat.com>,
	YunQiang Su <yunqiang.su@cipunited.com>,
	 binutils@sourceware.org, jiaxun.yang@flygoat.com
Subject: Re: [PATCH v4 1/2] MIPS: support mips*64 as CPU and gnuabi64 as ABI
Date: Sat, 22 Jul 2023 15:18:05 +0800	[thread overview]
Message-ID: <f56eced472ee05fed42d534086d1284a86c331a7.camel@xry111.site> (raw)
In-Reply-To: <CAKcpw6X1K6F4RSTdY0mcU5imQMTOSQ_eAeMW8g9StTpFdj-0Yg@mail.gmail.com>

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

  reply	other threads:[~2023-07-22  7:18 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-08  4:30 [PATCH 1/3] MIPS: Fix test failure with FPXX GCC YunQiang Su
2021-03-08  4:30 ` [PATCH 2/3] MIPS: default output r6 object if configured to r6 YunQiang Su
2023-02-23 11:11   ` [PATCH] MIPS: support specify isa level when configure YunQiang Su
2023-03-30 16:53     ` Richard Sandiford
2023-04-03 11:06     ` [PATCH v2] MIPS: the default output fellows triple and with-arch YunQiang Su
2023-04-03 12:40       ` Richard Sandiford
2023-04-10  7:01         ` YunQiang Su
2023-04-14  7:20       ` [PATCH v3] MIPS: the default output fellows triple YunQiang Su
2023-04-18 13:07         ` Richard Sandiford
2023-04-18 14:00         ` [PATCH v4 1/2] MIPS: support mips*64 as CPU and gnuabi64 as ABI YunQiang Su
2023-04-18 14:00           ` [PATCH v4 2/2] MIPS: default output r6 obj if the triple is r6 YunQiang Su
2023-04-19 19:03             ` Richard Sandiford
2023-04-20 13:31             ` [PATCH v5 1/2] MIPS: support mips*64 as CPU and gnuabi64 as ABI YunQiang Su
2023-04-20 13:31               ` [PATCH v5 2/2] MIPS: default output r6 obj if the triple is r6 YunQiang Su
2023-04-19 19:00           ` [PATCH v4 1/2] MIPS: support mips*64 as CPU and gnuabi64 as ABI Richard Sandiford
2023-07-21 10:00             ` Maciej W. Rozycki
2023-07-21 10:14               ` YunQiang Su
2023-07-21 11:54                 ` Maciej W. Rozycki
2023-07-21 12:30                   ` YunQiang Su
2023-07-21 14:30                     ` Maciej W. Rozycki
2023-07-21 15:01                       ` YunQiang Su
2023-07-22  7:18                         ` Xi Ruoyao [this message]
2023-07-25 13:30                           ` Nick Clifton
2023-07-25 14:00                             ` YunQiang Su
2023-07-25 16:03                             ` Maciej W. Rozycki
2023-07-31 10:05                         ` Maciej W. Rozycki
2023-07-31 10:32                           ` YunQiang Su
2023-08-01 22:52                             ` Maciej W. Rozycki
2023-07-25 17:47                       ` Andreas K. Huettel
2023-07-28  5:42                         ` YunQiang Su
2023-07-25 17:41                     ` Andreas K. Huettel
2021-03-08  4:30 ` [PATCH 3/3] MIPS: Fix testcase for MIPSr6 YunQiang Su
2021-03-19  5:47 ` 回复: [PATCH 1/3] MIPS: Fix test failure with FPXX GCC yunqiang.su

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f56eced472ee05fed42d534086d1284a86c331a7.camel@xry111.site \
    --to=xry111@xry111.site \
    --cc=binutils@sourceware.org \
    --cc=dilfridge@gentoo.org \
    --cc=jiaxun.yang@flygoat.com \
    --cc=macro@orcam.me.uk \
    --cc=nickc@redhat.com \
    --cc=richard.sandiford@arm.com \
    --cc=syq@debian.org \
    --cc=yunqiang.su@cipunited.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).