Created attachment 12247 [details] 0001-MIPS-default-output-as-r6-when-default-target-as-r6.patch currently we find 2 usecases with problem: 1. mipsisa32r6el-linux-gnu-ld -r -b binary xx.dat -o xx.o the output will be MIPS I, while we expect MIPS32r6. 2. mipsisa32r6el-linux-gnu-as -march=from-abi xx.s the output will be MIPS I, while we expect MIPS32r6.
Created attachment 12248 [details] fix testsuite
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.
(In reply to Maciej W. Rozycki from comment #2) > 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. Yes. It is right. While, we meet some problem in other software, for example gnome glib, which use the `ld' to produce object from data in its Makefile. If the result is MIPS I, and then, ld will refused to link it with other normal object files.
New patch: https://sourceware.org/pipermail/binutils/2023-February/126283.html
FIXED by: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=9171de358f230b64646bbb525a74e5f8e3dbe0dc