On Fri, 13 Jan 2023 at 14:25, Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx> wrote: > > On Fri, Jan 13, 2023 at 12:58 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > On Fri, 13 Jan 2023 at 12:50, Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx> wrote: > > > > > > Dear Ard, > > > > > > with my Ubuntu 18.04 arm gcc tool chain, I encounter this linker error > > > in my allyesconfig build: > > > > > > LD arch/arm64/boot/vmlinuz.efi.elf > > > aarch64-linux-gnu-ld: unknown architecture of input file > > > `arch/arm64/boot/vmlinuz.o' is incompatible with aarch64 output > > > drivers/firmware/efi/libstub/Makefile.zboot:41: recipe for target > > > 'arch/arm64/boot/vmlinuz.efi.elf' failed > > > make[1]: *** [arch/arm64/boot/vmlinuz.efi.elf] Error 1 > > > arch/arm64/Makefile:173: recipe for target 'vmlinuz.efi' failed > > > make: *** [vmlinuz.efi] Error 2 > > > > > > I bisected it back to happen since commit c37b830fef13 ("arm64: efi: > > > enable generic EFI compressed boot"), and it still appears with the > > > latest next-20230113 (on linux-next, I have to remove DRM_MSM as it > > > currently comes with a build error). > > > > > > The specific compiler and linker versions on my system are: > > > > > > $ aarch64-linux-gnu-ld --version > > > GNU ld (GNU Binutils for Ubuntu) 2.30 > > > > > > $ aarch64-linux-gnu-gcc --version > > > aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 > > > > > > > > > IMHO, I run pretty standard commands: > > > make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j 32 mrproper > > > make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j 32 allyesconfig > > > make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j 32 all > > > > > > Let me know if you need more information. > > > > > > > Hello Lukas, > > > > This seems to mean that AArch64 ld.bfd 2.30 is not able to combine > > generic ELF objects with AArch64 ELF objects. vmlinuz.o only contains > > a compressed blob in an ELF data section, and more modern toolchains > > have no issue with this at all. > > > > Given that building allyesconfig with fairly outdated toolchains is > > not something anyone is likely to obsess about, I don't have a strong > > preference as to how we work around this, put perhaps the easiest > > approach would be for CONFIG_EFI_ZBOOT to depend on !CONFIG_LD_IS_BFD > > || CONFIG_LD_VERSION >= 23xxx here? (We'll need to check the exact > > version) > > That sounds reasonable to me. > This is not reproducible with ld.bfd built from the upstream sources $ ~/build/binutils-build-aarch64/ld/ld-new -v GNU ld (GNU Binutils) 2.30 $ ~/build/binutils-build-aarch64/ld/ld-new -EL -maarch64elf -z noexecstack -T /usr/local/google/home/ardb/linux/drivers/firmware/efi/libstub/zboot.lds arch/arm64/boot/vmlinuz.o arch/arm64/boot/zboot-header.o drivers/firmware/efi/libstub/lib.a -o arch/arm64/boot/vmlinuz.efi.elf $ file arch/arm64/boot/vmlinuz.efi.elf arch/arm64/boot/vmlinuz.efi.elf: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, with debug_info, not stripped So this could be an issue in Ubuntu's downstream fork, in which case I don't think we should do anything about it.