YunQiang Su <[email protected]> writes:
> Richard Sandiford via Gcc-patches <[email protected]>
> 于2023年2月3日周五 20:29写道：
>>
>> YunQiang Su <[email protected]> writes:
>> > The value of default_mips_arch will be always used for -march by default,
>> > no matter what value is given to -mabi.
>> > It will produce abnormal elf file like:
>> > ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV)
>>
>> Is that really wrong though? There's nothing in principle that
>> prevents a 64-bit ISA being used with a 32-bit ABI, even in the
>> object file's metadata.
>>
>
> To make sure that there is no misunderstanding.
> The "wrong" format is
> ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV)
> ^^
> and the "correct" O32 ABI file is
> ELF 32-bit LSB relocatable, MIPS, MIPS32 rel2 version 1 (SYSV)
> ^^
> and the linker refuses to interlink them together.
>
> Do you mean that the "wrong" format is quite interesting?
> Yes, While this format is never used at all.
My point was that there is nothing wrong in principle with creating
an o32 executable that has a 64-bit rather than a 32-bit ISA (since the
64-bit ISAs are pure extensions of 32-bit ISAs). Doing that is even
useful in some cases. For example, MIPS4+O32 is a useful combination,
even though MIPS4 is a 64-bit ISA. Same for Octeon3+O32, etc.
So is the linker behaviour really correct? Doesn't it mean that
Octeon3 O32 binaries are link-incompatible with MIPS32 o32 binaries?
>> > So we use with_arch_32 and with_arch_64 instead of default_mips_arch
>> > for all mipsisa[32,64]rN triples.
>>
>> I agree there's no benefit to using a stock MIPS64rN ISA over
>> a stock MIPS32rN ISA with a 32-bit ABI, and the patch is only
>> changing those cases. But things are different when using
>> (say) MIPS4 with a 32-bit ABI, or a 64-bit processor that has
>> proprietary extensions.
>>
>> And, for example, a mips-linux-gnu toolchain would (IIRC) require
>> an -march as well as an -mabi in order to generate 64-bit code.
>> There would be no implicit selection of a new -march.
>>
>
> In fact, no: if we wish to use the default march of GCC configured,
> we can use -mabi=64 only.
>
> $ mipsel-linux-gnu-gcc -mabi=64 -c xx.c && file xx.o
> xx.o: ELF 64-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV),
> not stripped
Ah, OK, thanks for the correction. I obviously misremembered.
> There does be a problem:
> $ mipsel-linux-gnu-gcc -mabi=32 -march=mips64r2 -c xx.c && file xx.o
> xx.o: ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV),
> not stripped
> ^^
>> I'm not opposed to the patch. I just think we should be clear
>> about the underlying principle. If it's just that all MIPS32/64rN
>> toolchains should behave in the same way (like the sde and mti ones
>> do), then the patch looks good. But I don't think we should create
>> a general principle that -mabi determines/changes/downgrades -march.
>>
>
> In fact, I prefer what x86 does now:
> $ gcc -m32 -march=haswell -c -O3 xx.c && file xx.o
> xx.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
>
> But MIPS does like:
> $ mipsel-linux-gnu-gcc -mabi=32 -march=octeon -c yy.c && file yy.o
> yy.o: ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV),
> not stripped
> ^^
> $ mipsel-linux-gnu-gcc -mabi=32 -march=mips64r2 -c yy.c && file yy.o
> yy.o: ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV),
> not stripped
> ^^
>
> I hope I can fix this problem for MIPS, although I have no idea how to
> do so yet.
The current MIPS behaviour is what I'd expect though, given the
command lines.
file doesn't tell the full story. The ELF flags should also
distinguish between the -march=octeon and -march=mips64r2 cases.
Thanks,
Richard
>
>> Thanks,
>> Richard
>>
>> >
>> > gcc/ChangeLog:
>> > * config.gcc: use with_arch_32 and with_arch_64 instead of
>> > default_mips_arch for mipsisa[32,64]rN triples.
>> > ---
>> > gcc/config.gcc | 21 ++++++++++++++-------
>> > 1 file changed, 14 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/gcc/config.gcc b/gcc/config.gcc
>> > index f0958e1c959..0b6d093d847 100644
>> > --- a/gcc/config.gcc
>> > +++ b/gcc/config.gcc
>> > @@ -2518,13 +2518,16 @@ mips*-*-linux*) #
>> > Linux MIPS, either endian.
>> > extra_options="${extra_options} linux-android.opt"
>> > case ${target} in
>> > mipsisa32r6*)
>> > - default_mips_arch=mips32r6
>> > + with_arch_32="mips32r6"
>> > + with_arch_64="mips64r6"
>> > ;;
>> > mipsisa32r2*)
>> > - default_mips_arch=mips32r2
>> > + with_arch_32="mips32r2"
>> > + with_arch_64="mips64r2"
>> > ;;
>> > mipsisa32*)
>> > - default_mips_arch=mips32
>> > + with_arch_32="mips32"
>> > + with_arch_64="mips64"
>> > ;;
>> > mips64el-st-linux-gnu)
>> > default_mips_abi=n32
>> > @@ -2540,22 +2543,26 @@ mips*-*-linux*) #
>> > Linux MIPS, either endian.
>> > ;;
>> > mipsisa64r6*-*-linux-gnuabi64)
>> > default_mips_abi=64
>> > - default_mips_arch=mips64r6
>> > + with_arch_32="mips32r6"
>> > + with_arch_64="mips64r6"
>> > enable_mips_multilibs="yes"
>> > ;;
>> > mipsisa64r6*-*-linux*)
>> > default_mips_abi=n32
>> > - default_mips_arch=mips64r6
>> > + with_arch_32="mips32r6"
>> > + with_arch_64="mips64r6"
>> > enable_mips_multilibs="yes"
>> > ;;
>> > mipsisa64r2*-*-linux-gnuabi64)
>> > default_mips_abi=64
>> > - default_mips_arch=mips64r2
>> > + with_arch_32="mips32r2"
>> > + with_arch_64="mips64r2"
>> > enable_mips_multilibs="yes"
>> > ;;
>> > mipsisa64r2*-*-linux*)
>> > default_mips_abi=n32
>> > - default_mips_arch=mips64r2
>> > + with_arch_32="mips32r2"
>> > + with_arch_64="mips64r2"
>> > enable_mips_multilibs="yes"
>> > ;;
>> > mips64*-*-linux-gnuabi64 | mipsisa64*-*-linux-gnuabi64)
