bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/25494] [MIPS] default output as r6 when default target as r6


From: address@hidden
Subject: [Bug ld/25494] [MIPS] default output as r6 when default target as r6
Date: Fri, 24 Jul 2020 11:04:58 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=25494

Maciej W. Rozycki <macro@linux-mips.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |macro@linux-mips.org

--- Comment #2 from Maciej W. Rozycki <macro@linux-mips.org> ---
For linking in raw binary chunks of data the best approach is to use GAS
and its .incbin pseudo-op, e.g.:

$ cat xx.s
        .incbin xx.dat
$ mipsisa32r6el-linux-gnu-as -o xx.o xx.s

because even if we decide to make the default ABI configurable `ld -r -b
binary' won't be able to set all the various ABI flags a given build may
require.

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]