Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

binutils cannot produce mips64 toolchain with n64 ABI #174

Open
haboustak opened this issue Oct 3, 2023 · 2 comments
Open

binutils cannot produce mips64 toolchain with n64 ABI #174

haboustak opened this issue Oct 3, 2023 · 2 comments

Comments

@haboustak
Copy link

haboustak commented Oct 3, 2023

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 that mips64*-*-linux* defaults to n64 and introducing support for mips64*-*-linux*n32, but I would like to upstream a solution, if possible.

  1. Debian's binutils source package includes a patch that introduces a mips*64-*-linux-*gnuabi64 tuple
  2. It looks like a recent binutils commit (July 2023) has included support for Debian's -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 include mips*64*-*-linux*-*abi64 and maybe open a discussion on the binutils mailing list about -gnuabi64?

@haboustak
Copy link
Author

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

@richfelker
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants