public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: YunQiang Su <wzssyqa@gmail.com>
Cc: Ian Lance Taylor <iant@google.com>,
	Cary Coutant <ccoutant@gmail.com>,
	 YunQiang Su <yunqiang.su@cipunited.com>,
	binutils@sourceware.org
Subject: Re: [PATCH] MIPS: recoginze mipsisa64 as 64bit CPU
Date: Sun, 20 Aug 2023 16:21:01 +0100 (BST)	[thread overview]
Message-ID: <alpine.DEB.2.21.2308201548010.49340@angie.orcam.me.uk> (raw)
In-Reply-To: <CAKcpw6WLjNSib9yDHg9avwVZMEHALJn6eZBOwN6DEu-M-OjpUQ@mail.gmail.com>

[Ian, Cary -- please see my notes about GOLD at the end; I'll appreciate 
your input.]

On Sun, 20 Aug 2023, YunQiang Su wrote:

> >  The change description has to be explicit in that we only refer to Linux
> > configurations here, as it doesn't change the semantics of `mipsisa64*'
> > CPUs for other OSes.  And it's not that we don't consider the CPU 64-bit
> > for `mipsisa64*-*-linux*' configurations.  We just don't use a 64-bit ABI
> > by default.  Finally there's no need to repeat the rules for ABI selection
> > as we just follow the existing ones for `mips64*-*-linux*' configurations.
> >
> >  How about:
> >
> > MIPS: Use a 64-bit ABI by default for `mipsisa64*-*-linux*' targets
> >
> 
> I use ABIs here, since they are both N32 and/or N64.

 But only one at a time, hence the singular.  You can't have n32 and n64 
as the default both at a time (in which case you'd use the plural form).

 I realise your view might be a consequence from how you express things in 
your native language, but this is how English grammar works (as how it is 
the case with many if not all of the European languages, most of which 
derive from a common ancestor in the Middle East thousands of years ago).

 NB mind the lowercase "n" in n32 and n64.  I realise people started 
mixing things up later on, but these were the correct spellings as the 
ABIs were invented (along with o32 and less officially o64) back in 1990s.  
There's no need to spread the mixed up form.

> > > diff --git a/gold/configure.tgt b/gold/configure.tgt
> > > index 4b54e08d27f..d09bb76ef02 100644
> > > --- a/gold/configure.tgt
> > > +++ b/gold/configure.tgt
> > > @@ -153,13 +153,27 @@ aarch64*-*)
> > >   targ_big_endian=false
> > >   targ_extra_big_endian=true
> > >   ;;
> > > -mips*el*-*-*|mips*le*-*-*)
> > > +mips64*el*-*-* | mipsisa64*le*-*-*)
> > > + targ_obj=mips
> > > + targ_machine=EM_MIPS_RS3_LE
> > > + targ_size=64
> > > + targ_big_endian=false
> > > + targ_extra_big_endian=true
> > > + ;;
> > > +mips*el*-*-*)
> >
> >  You are removing the `mips*le*-*-*' configuration here.  It may well be
> > the right move given that no other binutils component has it, but it has
> > to be a separate change.
> >
> 
> You are right. I will add it back.

 I suggest the opposite, that is to remove it with a separate patch, as 
it couldn't have been a usable configuration ever.  It must have slipped 
through review.

> > >   targ_obj=mips
> > >   targ_machine=EM_MIPS_RS3_LE
> > >   targ_size=32
> > >   targ_big_endian=false
> > >   targ_extra_big_endian=true
> > >   ;;
> > > +mips64*-*-* | mipsisa64*-*-*)
> > > + targ_obj=mips
> > > + targ_machine=EM_MIPS
> > > + targ_size=64
> > > + targ_big_endian=true
> > > + targ_extra_big_endian=false
> > > + ;;
> >
> >  Also you're adding new 64-bit MIPS support to GOLD here, so it has to be
> > a separate patch too from the changes to the other binutils components.
> > Is it a working configuration for GOLD even?  Doesn't it need to have
> 
> In fact, the current configure.tgt makes something wrong, if we configure
> it with --with-targets=mips64-linux-gnuabi64.
> https://buildd.debian.org/status/fetch.php?pkg=binutils-mipsen&arch=amd64&ver=10%2Bc5&stamp=1692086940&raw=0
> 
> That's why I'd like to put them in a single patch.

 You can fix GOLD to match the rest of the tools first, i.e. add support 
for `mips64*el-*-linux*' and `mips64*-*-linux*' only with a preparatory 
patch before the rest of the series to be considered.  This way you won't 
add an inconsistency.  This seems like the best approach, as we can shake 
out the issues there with the conventional n32-by-default configurations 
before adding n64-by-default support treewide.

> > `targ_extra_size' also set?
> 
> Maybe no.
> Since `configure.tgt` is used for --enable-targets=xx,yy option.
> WIth this option, only the list extra targets should be support.
> If we set it, 32bit targets will be supported anyway.

 Why do other targets such as `x86_64*', `sparc64-*', `powerpc64le-*', 
`aarch64*-*', etc. set it then?

> If user wants to support all targets, they need to use
>    --with-targets=all

 You mean `--enable-targets' I guess, but that's no news of course.  But 
other multiple-ABI 64-bit configurations (and some 32-bit ones) chose to 
have their 32-bit counterparts always included in GOLD, as we do too in 
BFD, GAS, LD.  So why do you want GOLD to be different?

 Cc-ing GOLD maintainers in case they want to chime in as GOLD is not my 
usual part of interest in binutils.

  Maciej

  reply	other threads:[~2023-08-20 15:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-15 10:48 YunQiang Su
2023-08-17 12:36 ` Maciej W. Rozycki
2023-08-20 13:53   ` YunQiang Su
2023-08-20 15:21     ` Maciej W. Rozycki [this message]
2023-08-20 16:00       ` 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=alpine.DEB.2.21.2308201548010.49340@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=binutils@sourceware.org \
    --cc=ccoutant@gmail.com \
    --cc=iant@google.com \
    --cc=wzssyqa@gmail.com \
    --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).