clang-12: Unsupported relocation type: R_386_PLT32

[arndb]

The latest clang-12 fails to build some 32-bit x86 kernels:

Unsupported relocation type: R_386_PLT32 (4)
make[5]: *** [/git/arm-soc/arch/x86/boot/compressed/Makefile:120: arch/x86/boot/compressed/vmlinux.relocs] Error 1

This was no problem with a slightly older clang-12 snapshot, or with the latest clang-11.

[nickdesaulniers]

Didn't @nivedita76 do some work to avoid PLT relocations in 32b x86 boot/?

[nivedita76]

@arndb Is that from arch/x86/tools/relocs? That indicates a PLT32 relocation in the main kernel, which is unrelated to the boot/compressed work. The tool handles PLT relocs on 64-bit but apparently not on 32-bit, not sure why: they should be equivalent to PC32 on both, right?

[nivedita76]

@MaskRay seems to have a commit that looks vaguely related, though I'd not expect it to produce R_386_PLT32 looking at the description.
https://reviews.llvm.org/rG37f0c8df47d84ba311fc9a2c1884935ba8961e84

hjl says R_386_PLT32 should only be produced for PIC code, though I don't quite follow the reasoning.
https://llvm.org/pr36674

[arndb]

Yes, to confirm, this is PLT32 relocations in the main kernel. I don't have a reproducer at hand (currently building with clang-11, but could go back to clang-12 if needed), but from what I remember, it appeared that the PLT32 relocations were for compiler-generated function calls to things like memset(), memcpy() or stackprotector, not for normal function calls.

[MaskRay]

@MaskRay seems to have a commit that looks vaguely related, though I'd not expect it to produce R_386_PLT32 looking at the description.
https://reviews.llvm.org/rG37f0c8df47d84ba311fc9a2c1884935ba8961e84

hjl says R_386_PLT32 should only be produced for PIC code, though I don't quite follow the reasoning.
https://llvm.org/pr36674

There is no fundamental reason that GNU as's i386 port cannot use R_386_PLT32. Once it does, we can change LLVM MC as well.

Actually, PLT32 is preferred (see https://sourceware.org/pipermail/binutils/2020-April/000424.html).
https://llvm.org/pr36674 is probably about (a) establishing the convention that PC32 is for -fno-pic and non-pic PLT while PLT32 is for -fpie/-fpic and pic PLT (b) some legacy software processing relocations does not support PLT32.

commit 2585b7a5ce5830e60a089aa2316a329558902f0c
Author: H.J. Lu <hidden>
Date:   Sun Jul 19 06:51:32 2020

    x86: Change PLT32 reloc against section to PC32
    
    Commit 292676c1 resolved PLT32 reloc aganst local symbol to section.
    Since PLT32 relocation must be against symbols, turn such PLT32
    relocation into PC32 relocation.

I have tried make -sk -j 50 ARCH=i386 LLVM=1 O=/tmp/out/i386 -j 50 i386_defconfig vmlinux with Clang built today and it works.

[arndb]

I got a minimized test case: https://godbolt.org/z/GP7q7a

All compilers turn a strcat() into strlen() plus store, but the generated call to strlen() in clang-12 uses a PLT32 reloc.

[arndb]

I think it happens to work in defconfig because we build i386 with -ffreestanding, which prevents the strcat() optimization from my example (I have a local patch to remove the -ffreestanding), and the defconfig does not generate calls to __stack_chk_fail(), which have the same problem when enabled.

[MaskRay]

The difference is due to [TargetMachine] Don't imply dso_local on function declarations in Reloc::Static model for ELF/wasm.

LLVM synthesized function declarations (e.g. strlen, as opposed to declarations written by the user) do not have the dso_local specifier. PLT32 can prevent canonical PLT entries (SHN_UNDEF with non-zero st_value) and is thus preferred. I think in the kernel no function can be preemptible (interposable) and thus every PLT32 will be handled the same way as PC32.

arch/x86/tools/relocs.c and arch/x86/kernel/module.c should handle R_386_PLT32 similar to R_386_PC32.

[nivedita76]

I think it happens to work in defconfig because we build i386 with -ffreestanding, which prevents the strcat() optimization from my example (I have a local patch to remove the -ffreestanding), and the defconfig does not generate calls to __stack_chk_fail(), which have the same problem when enabled.

@nickdesaulniers did https://lore.kernel.org/lkml/20200817220212.338670-5-ndesaulniers@google.com/ not get merged?

[nickdesaulniers]

@nickdesaulniers did https://lore.kernel.org/lkml/20200817220212.338670-5-ndesaulniers@google.com/ not get merged?

I don't think so; 1e1b6d6 is ultimately what shipped.

[MaskRay]

I'll post a kernel patch.

--- i/arch/x86/Makefile
+++ w/arch/x86/Makefile
@@ -75,7 +75,7 @@ ifeq ($(CONFIG_X86_32),y)
         KBUILD_CFLAGS += $(cflags-y)
 
         # temporary until string.h is fixed
-        KBUILD_CFLAGS += -ffreestanding
+        #KBUILD_CFLAGS += -ffreestanding
 else
         BITS := 64
         UTS_MACHINE := x86_64

With top-of-trunk clang, this reproduces

(cd ~/Dev/linux; PATH=/tmp/RelA/bin:$PATH make -sk -j 50 ARCH=i386 LLVM=1 O=/tmp/out/i386 -j 50 i386_defconfig all )