Bug 25136 - mips64: set abi as N64 when the ABI section triple is gnuabi64
Summary: mips64: set abi as N64 when the ABI section triple is gnuabi64
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-27 08:52 UTC by YunQiang Su
Modified: 2023-04-23 06:49 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description YunQiang Su 2019-10-27 08:52:32 UTC 
https://sources.debian.org/patches/binutils/2.33.1-2/mips64-default-n64.diff/

For historical reasons,
   mips64*-linux-gnu
is set as N32, so some distributions like Debian use
   -gnuabi64
as their ABI section for N64 port.

So we should set all 
   mips*64*-linux-gnuabi64
as N64.
Comment 1 YunQiang Su 2019-10-27 08:57:59 UTC 
The reason change
   mips64* 
to
   mips*64*
is that for MIPS r6,
we use something like
   mipsisa64r6el-linux-gnuabi64

Since config.guess and config.sub use it.
Comment 3 YunQiang Su 2020-03-02 04:20:48 UTC 
we need to fix the testsuite
Comment 4 Maciej W. Rozycki 2020-07-24 11:05:01 UTC 
As to making the default ABI/ISA configurable I would recommend reusing
the approach we have taken with GCC, that is to provide `--with-abi=',
`--with-arch=', `--with-arch-32=' and `--with-arch-64=' configuration
options.  This way the toolchain will remain consistent and will not
depend on the target triplet in a different way across packages, and also
we won't have to invent more and more complicated target triplets to
handle new cases as they arise.  As I recall this design decision has
been discussed a few times over the years.

Please note that GAS/LD are low-level tools however and in ordinary use
cases they are supposed to be driven by GCC, which will set correct flags
according to its configuration and any additional options requested.  I'm
not therefore sure we need to change the semantics in the first place.
What is your use case that requires GAS/LD to be invoked directly rather
than via GCC?

Cf. PR ld/25494.
Comment 5 YunQiang Su 2021-02-28 08:51:49 UTC 
(In reply to Maciej W. Rozycki from comment #4)
> As to making the default ABI/ISA configurable I would recommend reusing
> the approach we have taken with GCC, that is to provide `--with-abi=',
> `--with-arch=', `--with-arch-32=' and `--with-arch-64=' configuration
> options.  This way the toolchain will remain consistent and will not
> depend on the target triplet in a different way across packages, and also
> we won't have to invent more and more complicated target triplets to
> handle new cases as they arise.  As I recall this design decision has
> been discussed a few times over the years.
> 
> Please note that GAS/LD are low-level tools however and in ordinary use
> cases they are supposed to be driven by GCC, which will set correct flags
> according to its configuration and any additional options requested.  I'm
> not therefore sure we need to change the semantics in the first place.
> What is your use case that requires GAS/LD to be invoked directly rather
> than via GCC?
> 
> Cf. PR ld/25494.

Yes. the correct way to invoke as/ld is by gcc, while in the real Linux distributions world, just like Debian, there are so many software invoke as/ld directly.

To compatiable with them, we have to make our toolchain in the way as they expect.