Re: [PATCH] MIPS: recoginze mipsisa64 as 64bit CPU

[YunQiang Su <wzssyqa@gmail.com>]

Maciej W. Rozycki <macro@orcam.me.uk> 于2023年8月20日周日 23:21写道：
>
> [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).
>

Yes. You are right. I have not very clear about since I was in junior
high school,
when I started to learn English, ;)

>  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.
>

OK, Send.

> > > >   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.
>

N32-or-N64 default is another topic for gold here, I guess.

> > > `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?
>

I have no idea. And in fact, I think that there is no standard way:
   i?86 doesn't enable 64bit support. while ppc does.

For aarch64, I believe it should be a mistake, as it has no 32bit
mode.( correct me if I am wrong.

For me, I think that  we should follow what users ask us to do.
If they need to support more, they can use "--enable-targets".

> > 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?
>

Adding all EL/EB/32/64 etc support sounds like a good idea.
I didn't do this, due to the previous mips* ones not enabling 64 bit support.

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



-- 
YunQiang Su