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
next prev parent 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).