MIPS64: Compilation error on Ubuntu 24.04

[pbatard]

When compiling gnu-efi for mips64 on Ubuntu 24.04 (make ARCH=mips64 CROSS_COMPILE=mips64el-linux-gnuabi64-), the following error is produced when building the apps:

mips64el-linux-gnuabi64-ld -nostdlib  --warn-common --no-undefined --fatal-warnings --build-id=sha1 -z nocombreloc -z norelro -L/usr/src/gnu-efi//apps/../mips64el/lib -L/usr/src/gnu-efi//apps/../mips64el/gnuefi /usr/src/gnu-efi//apps/../mips64el/gnuefi/crt0-efi-mips64el.o -shared -Bsymbolic -L/usr/src/gnu-efi//apps/../mips64el/lib --defsym=EFI_SUBSYSTEM=0xa t.o -o t.so -T /usr/src/gnu-efi//apps/../gnuefi/elf_mips64el_efi.lds -lefi -lgnuefi /usr/lib/gcc-cross/mips64el-linux-gnuabi64/12/libgcc.a
mips64el-linux-gnuabi64-ld: /usr/src/gnu-efi//apps/../mips64el/gnuefi/crt0-efi-mips64el.o: in function `extra_header_fields':
(.text.head+0x9c): warning: internal error: unsupported relocation error
make[1]: *** [/usr/src/gnu-efi//apps/../Make.rules:52: t.so] Error 1
make[1]: Leaving directory '/usr/src/gnu-efi/mips64el/apps'
make: *** [Makefile:89: apps] Error 2

# mips64el-linux-gnuabi64-ld --version
GNU ld (GNU Binutils for Ubuntu) 2.42

This is likely to impact us with automated builds when GitHub Actions switches their ubuntu-latest builder from 22.04 to 24.04 (and this issue was actually discovered when I tested some builds with GitHub Actions on their ubuntu-24.04 builder).

[ncroxon]

I'm not a big cross compiler.. but I tried and ran into a different issue.

$ make ARCH=mips64 CROSS_COMPILE=mips64-linux-gnu-
mkdir -p /home/ncroxon/kwf/gnu-efi/mips64el/lib
make -C /home/ncroxon/kwf/gnu-efi/mips64el/lib -f /home/ncroxon/kwf/gnu-efi//lib/Makefile SRCDIR=/home/ncroxon/kwf/gnu-efi//lib ARCH=mips64el
make[1]: Entering directory '/home/ncroxon/kwf/gnu-efi/mips64el/lib'
CC boxdraw.o
CC smbios.o
CC console.o
CC crc.o
CC data.o
CC debug.o
CC dpath.o
CC entry.o
CC error.o
CC event.o
CC exit.o
CC guid.o
CC hand.o
CC hw.o
CC init.o
CC lock.o
CC misc.o
CC pause.o
CC print.o
CC sread.o
CC str.o
CC cmdline.o
CC rtlock.o
CC efirtlib.o
CC rtstr.o
CC vm.o
CC rtdata.o
CC initplat.o
CC math.o
CC setjmp.o
CC ctors.o
AR libefi.a
mips64-linux-gnu-ar: creating libefi.a
make[1]: Leaving directory '/home/ncroxon/kwf/gnu-efi/mips64el/lib'
mkdir -p /home/ncroxon/kwf/gnu-efi/mips64el/inc
make -C /home/ncroxon/kwf/gnu-efi/mips64el/inc -f /home/ncroxon/kwf/gnu-efi//inc/Makefile SRCDIR=/home/ncroxon/kwf/gnu-efi//inc ARCH=mips64el
make[1]: Entering directory '/home/ncroxon/kwf/gnu-efi/mips64el/inc'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/ncroxon/kwf/gnu-efi/mips64el/inc'
mkdir -p /home/ncroxon/kwf/gnu-efi/mips64el/gnuefi
make -C /home/ncroxon/kwf/gnu-efi/mips64el/gnuefi -f /home/ncroxon/kwf/gnu-efi//gnuefi/Makefile SRCDIR=/home/ncroxon/kwf/gnu-efi//gnuefi ARCH=mips64el
make[1]: Entering directory '/home/ncroxon/kwf/gnu-efi/mips64el/gnuefi'
CC crt0-efi-mips64el.o
CC reloc_mips64el.o
In file included from /home/ncroxon/kwf/gnu-efi//gnuefi/reloc_mips64el.c:42:
/home/ncroxon/kwf/gnu-efi//gnuefi/../inc/subst/elf.h:15:10: fatal error: elf.h: No such file or directory
15 | #include <elf.h>
| ^~~~~~~
compilation terminated.
make[1]: *** [/home/ncroxon/kwf/gnu-efi//gnuefi/../Make.rules:71: reloc_mips64el.o] Error 1
make[1]: Leaving directory '/home/ncroxon/kwf/gnu-efi/mips64el/gnuefi'
make: *** [Makefile:89: gnuefi] Error 2

[gmbr3]

#include <elf.h>

Looks like missing glibc-headers

[pbatard]

I'm not seeing this on my platform.

It does look like you invoked the build with a different tuple than what I tested with though: make ARCH=mips64 CROSS_COMPILE=mips64el-linux-gnuabi64- vs make ARCH=mips64 CROSS_COMPILE=mips64-linux-gnu-.

You may want to reinstall the MIP64 toolchain with apt install gcc-mips64-linux-gnuabi64 and then try with the same tuple.

[ncroxon]

Yes, testing with a different distro - running on RHEL-9.1.
I have glibc-headers.. for x86_64.. but not for mips64...

[gmbr3]

Yes, testing with a different distro - running on RHEL-9.1. I have glibc-headers.. for x86_64.. but not for mips64...

Should be the same (it's arch independent), looks like it's missing /usr/include from system header path, we could force include it using (-isystem)

[gmbr3]

@ncroxon @pbatard Any change? Maybe re-test with NO_GLIBC=1 to fix the headers issue

Is this a blocker for 4.0.0 or do we publish this week anyways?

[ncroxon]

Pete (@pbatard) needs to test your two suggestions
NO_GLIBC=1
or
force with -isystem header path.

[pbatard]

I never had the header issue in the first place, so NO_GLIBC=1 doesn't help.

From what I can tell, the core of the issue is that the MIPS linker is unable to properly resolve the EFI_SUBSYSTEM macro at

gnu-efi/gnuefi/crt0-efi-mips64el.S

Line 71 in 70b1421

.2byte EFI_SUBSYSTEM // Subsystem

which should be treated as a numeric literal by the assembler, since that's how we provide it (through a symbol macro), but instead ends up being treated as some kind of relocation symbol.

And of course, the issue is we can't just hardcode EFI_SUBSYSTEM, because we need to define it differently according to what the user is building, hence the reason for macro use.

My testing shows that the MIPS assembler does properly parse the --defsym=EFI_SUBSYSTEM=$(SUBSYSTEM) value we set up (because if it's not defined, you do get an undefined reference to 'EFI_SUBSYSTEM' instead of a relocation error), so it looks like a compiler bug was introduced in newer versions of the MIPS assembler, where it treats the defined value of a symbol as a relocation rather than a straight literal.

And once again, this has nothing to do with a header error, which is something Nigel experienced on a different platform, but which I never got on Ubuntu.

[gmbr3]

My testing shows that the MIPS assembler does properly parse the --defsym=EFI_SUBSYSTEM=$(SUBSYSTEM) value we set up (because if it's not defined, you do get an undefined reference to 'EFI_SUBSYSTEM' instead of a relocation error), so it looks like a compiler bug was introduced in newer versions of the MIPS assembler, where it treats the defined value of a symbol as a relocation rather than a straight literal.

What happens if you re-write it as EFI_SUBSYSTEM - ImageBase (ImageBase is a trick to make it read as a literal)

And once again, this has nothing to do with a header error, which is something Nigel experienced on a different platform, but which I never got on Ubuntu.

I know that was in case Nigel tested it

[pbatard]

What happens if you re-write it as EFI_SUBSYSTEM - ImageBase (ImageBase is a trick to make it read as a literal)

/usr/src/gnu-efi//gnuefi/crt0-efi-mips64el.S: Assembler messages:
/usr/src/gnu-efi//gnuefi/crt0-efi-mips64el.S:71: Error: PC-relative reference to a different section

Good try though...

[pbatard]

Trying to force computation in case it helps with symbol resolution (with something like .2byte 10 + EFI_SUBSYSTEM) also still produces the original relocation error. This is a weird bug, because everything seems to point to the symbol being resolved at assembly time, but the resulting data value not treated as a numeric literal...

[pbatard]

Considering that this is unlikely to be resolved soon, and that we are now getting the following from our GitHub Actions runs:

ubuntu-latest pipelines will use ubuntu-24.04 soon. For more details, see https://github.com/actions/runner-images/issues/10636

I think we have to look into removing MIPS builds from GitHub Actions (for which we don't run tests anyway, since we don't have a MIPS UEFI firmware for QEMU).

So, unless there are objections, I will also be submitting a PR that does just that (which of course will not be removing MIPS support from gnu-efi, just the GitHub Actions builds).