s390: ld.lld: error: unknown emulation: elf64_s390

[emojifreak]

Kernel version is 5.16rc3 and 5.15.5. As arch/s390/Kconfig has the following line, s390 seems somewhat supported by clang:

config COMPAT
        def_bool y
        prompt "Kernel support for 31 bit emulation"
        select ARCH_WANT_OLD_COMPAT_IPC
        select COMPAT_OLD_SIGACTION
        select HAVE_UID16
        depends on MULTIUSER
        depends on !CC_IS_CLANG

A config similar to allmodconfig gives the following error at an early stage of build:

  LDS     arch/s390/kernel/vdso64/vdso64.lds
  VDSO64A arch/s390/kernel/vdso64/vdso_user_wrapper.o
  VDSO64A arch/s390/kernel/vdso64/note.o
  VDSO64C arch/s390/kernel/vdso64/vdso64_generic.o
  VDSO64C arch/s390/kernel/vdso64/getcpu.o
  LD      arch/s390/kernel/vdso64/vdso64.so.dbg
ld.lld: error: unknown argument '-fPIC'
ld.lld: error: unknown emulation: elf64_s390
make[1]: *** [arch/s390/kernel/vdso64/Makefile:50: arch/s390/kernel/vdso64/vdso64.so.dbg] Error 1
make[1]: Target 'include/generated/vdso64-offsets.h' not remade because of errors.
make: *** [arch/s390/Makefile:165: vdso_prepare] Error 2

It can be reproduced by the below script:

#!/bin/sh

KVER=5.16-rc3
LANG=C.UTF-8
export LANG
cd /var/tmp/tmp11s390

  cat >/tmp/config$$.txt <<EOF
CONFIG_FTRACE_MCOUNT_USE_RECORDMCOUNT=n
CONFIG_KASAN=n
CONFIG_GCOV_KERNEL=n
CONFIG_COMPILE_TEST=n
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y
CONFIG_INIT_STACK_ALL_ZERO=y
CONFIG_KVM=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_DYNAMIC=y

CONFIG_WERROR=n
CONFIG_RUNTIME_TESTING_MENU=n
CONFIG_XFS_FS=n
CONFIG_OVERLAY_FS=n
CONFIG_EMBEDDED=n

CONFIG_ACPI=y
CONFIG_EFI_STUB=y
CONFIG_EFI=y
CONFIG_DMI=y
CONFIG_NUMA=y
CONFIG_MEMORY_HOTPLUG=y
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_PCIE=y
CONFIG_HOTPLUG_CPU=y

CONFIG_MARCH_Z15=y
CONFIG_TUNE_Z15=y
CONFIG_SCHED_TOPOLOGY=y
EOF


for a in s390; do
  rm -rf /var/tmp/tmp11s390/$a
  mkdir /var/tmp/tmp11s390/$a
  cd /var/tmp/tmp11s390/$a
  exec </dev/null >build-log-${KVER}-${a}.txt 2>&1
  set -xe
  tar zxf /var/tmp/linux-${KVER}.tar.gz
  cd linux-${KVER}

  cp /tmp/config$$.txt .config
  make LLVM=1 LLVM_IAS=1 allmodconfig
  cat /tmp/config$$.txt >>.config

  yes '' |
    chrt --idle 0 nice -19 make --keep-going ARCH=$a LLVM=1 LLVM_IAS=1 all &
  exec </dev/null >/dev/null 2>&1
done 
wait

[nathanchance]

s390 is supported by clang but not ld.lld. Use LD=s390x-linux-gnu-ld in the meantime (I am not sure that there is any timeline for supporting it, maybe @uweigand does?)

[nathanchance]

The error actually comes from https://github.com/llvm/llvm-project/blob/2f16b87b4b1d3fee07aff71a9bf79c3a8d514e7a/lld/ELF/Driver.cpp#L138-L174. There is no s390 file in lld/ELF/Arch so I assume it is intentional that s390 is not supported by ld.lld.

[uweigand]

Yes, there is currently no support for s390x as a target in lld. We are not currently planning to add this in the near time - so far we have not seen any particular use case where lld would be required / provide benefit over ld.

[nathanchance]

llvm/llvm-project#75643

[nathanchance]

The kernel needed some changes, which I have sent https://lore.kernel.org/20240207-s390-lld-and-orphan-warn-v1-0-8a665b3346ab@kernel.org/ after testing the LLVM pull request with both Clang and GCC.

[nathanchance]

The LLVM pull request has been merged: llvm/llvm-project@fe3406e

I am going to close this issue up, as this particular error has been fixed with that change.

We still need objcopy and objdump support for full LLVM=1 as far as I am aware:

#1530
#859

I have filed issues for each of the distinct problems I have seen on the Linux side in my testing of that pull request so that they can be tracked properly.

#1991
#1992
#1993
#1994
#1995

Once apt.llvm.org includes the above ld.lld change, we should be able to wire this up in continuous integration for -next:

ClangBuiltLinux/continuous-integration2#710

Thanks again @uweigand for resolving this, it was awesome to see how much more robust the kernel gets now that there is a second linker implementation that we can use :)