Open haboustak opened 11 months ago
I wanted to add a note to clarify, there's existing support for n32
in the build of GCC via --with-abi=n32
, but there's no corresponding option in binutils.
The toolchain that results from TARGET=mips64-linux-musl
uses the n64
ABI as long as you build and link with gcc
and you don't use ld
or objcopy
.
If you link using mips64-linux-musl-ld
it cannot build a 32-bit ELF from 64-bit objects:
# make test CC=mips64-linux-musl-gcc LD=mips64-linux-musl-ld
mips64-linux-musl-gcc -c -o test.o test.c
mips64-linux-musl-ld test.o -o test
mips64-linux-musl-ld: test.o: ABI is incompatible with that of the selected emulation
mips64-linux-musl-ld: failed to merge target specific data of file test.o
mips64-linux-musl-ld: warning: cannot find entry symbol __start; defaulting to 0000000010000090
test.o: in function `main':
test.c:(.text+0x20): relocation truncated to fit: R_MIPS_GOT_PAGE against `.rodata'
test.c:(.text+0x24): relocation truncated to fit: R_MIPS_GOT_OFST against `.rodata'
make: *** [Makefile:11: test] Error 1
In general, you cannot use the ld
command except in situations where you know the exact target ABI or you're doing bare metal stuff on a known target. There are lots of arch/ABI combinations where you need a number of options the compiler driver (gcc
) passes to the raw ld
in order to get a valid link.
It does seem unfortunate if the objcopy
command is uniquely broken on mips64.
In any case, mcm is producing a toolchain (invoked via the compiler driver mips64-linux-musl-gcc
) with the right ABI, and the same target-specific annoyances as the upstream binutils seems to have on every mips64 target. If there are minor configure-time tweaks we could make in the default config to get nicer behavior, that would probably be appropriate, but otherwise this issue is probably something you should raise with upstream binutils. Changing/improving the basic binutils behavior is pretty much outside the scope of this project.
For some reason that is not yet completely clear to me, the
mips64*-*-linux*
targets in binutils 2.33.1 default to the n32 ABI, rather than n64.There are no additional variants to choose the n64 ABI, and so it's not possible to build a mips64 toolchain with the n64 ABI using musl-cross-make.
I have been including a local patch for
binutils-2.32
so thatmips64*-*-linux*
defaults ton64
and introducing support formips64*-*-linux*n32
, but I would like to upstream a solution, if possible.mips*64-*-linux-*gnuabi64
tuple-gnuabi64
.For upstream binutils, I think they at least should have used
mips*64*-*-linux*-*abi64
to get the GNU out of the ABI specifier.Does it make sense to patch
binutils
here in musl-cross-make to includemips*64*-*-linux*-*abi64
and maybe open a discussion on thebinutils
mailing list about-gnuabi64
?