clang-12: Unsupported relocation type: R_386_PLT32 #1210

arndb · 2020-12-07T13:40:21Z

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 · 2020-12-07T21:11:47Z

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

nivedita76 · 2020-12-07T21:19:22Z

@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 · 2020-12-07T21:34:34Z

@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 · 2020-12-07T22:01:17Z

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 · 2020-12-08T06:00:23Z

@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 · 2020-12-08T09:23:00Z

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 · 2020-12-08T09:26:47Z

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 · 2020-12-08T17:09:12Z

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 · 2020-12-08T17:14:14Z

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 · 2020-12-08T21:01:51Z

@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.

running kernel with CONFIG_DEBUG_LOCKS_ALLOC enabled will below warning: BUG: key ffff502e09807098 has not been registered! DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 5 PID: 129 at kernel/locking/lockdep.c:4623 lockdep_init_map_waits+0xe8/0x250 Modules linked in: CPU: 5 PID: 129 Comm: kworker/5:1 Tainted: G W 5.10.0-rc1-00277-ged49f224ca3f-dirty #1210 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Workqueue: events deferred_probe_work_func pstate: 80c00005 (Nzcv daif +PAN +UAO -TCO BTYPE=--) pc : lockdep_init_map_waits+0xe8/0x250 lr : lockdep_init_map_waits+0xe8/0x250 [ Trimmed ] Call trace: lockdep_init_map_waits+0xe8/0x250 __kernfs_create_file+0x78/0x180 sysfs_add_file_mode_ns+0x94/0x1c8 internal_create_group+0x110/0x3e0 sysfs_create_group+0x18/0x28 devm_device_add_group+0x4c/0xb0 add_all_attributes+0x438/0x490 sdw_slave_sysfs_dpn_init+0x128/0x138 sdw_slave_sysfs_init+0x80/0xa0 sdw_drv_probe+0x94/0x170 really_probe+0x118/0x3e0 driver_probe_device+0x5c/0xc0 [ Trimmed ] CPU: 5 PID: 129 Comm: kworker/5:1 Tainted: G W 5.10.0-rc1-00277-ged49f224ca3f-dirty #1210 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Workqueue: events deferred_probe_work_func Call trace: dump_backtrace+0x0/0x1c0 show_stack+0x18/0x68 dump_stack+0xd8/0x134 __warn+0xa0/0x158 report_bug+0xc8/0x178 bug_handler+0x20/0x78 brk_handler+0x70/0xc8 [ Trimmed ] Fix this by initializing dynamically allocated sysfs attribute to keep lockdep happy! Fixes: bcac590 ("soundwire: add Slave sysfs support") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20201104112941.1134-1-srinivas.kandagatla@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>

MaskRay · 2021-01-06T23:33:35Z

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 )

MaskRay · 2021-01-06T23:51:05Z

edit: Sent [PATCH] x86: Treat R_386_PLT32 as R_386_PC32

From f09216123597624e1d07e6c136f75054f82a8d2c Mon Sep 17 00:00:00 2001
From: Fangrui Song <hidden>
Date: Wed, 6 Jan 2021 15:56:02 -0800
Subject: [PATCH] x86: Treat R_386_PLT32 as R_386_PC32

This is similar to commit b21ebf2fb4cde1618915a97cc773e287ff49173e "x86:
Treat R_X86_64_PLT32 as R_X86_64_PC32", but for i386.  As far as Linux
kernel is concerned, R_386_PLT32 can be treated the same as R_386_PC32.

R_386_PC32/R_X86_64_PC32 are PC-relative relocation types with the
requirement that the symbol address is significant.
R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types without the
address significance requirement.

On x86-64, there is no PIC vs non-PIC PLT distinction and R_X86_64_PLT32
is used for `call/jmp foo` and `call/jmp foo@PLT` with newer (2018) GNU
as/LLVM integrated assembler.

On i386, there are 2 types of PLTs, PIC and non-PIC. Currently the
convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC
PLT but R_386_PLT32 is arguably preferable for -fno-pic code as well:
this can avoid a "canonical PLT entry" (st_shndx=0, st_value!=0) if the
symbol turns out to be defined externally. Latest Clang (since
961f31d8ad14c66829991522d73e14b5a96ff6d4) can use R_386_PLT32 for
compiler produced symbols (if we drop -ffreestanding for CONFIG_X86_32)
and future GCC may use R_386_PLT32 as well if the maintainers agree to
adopt an option like -fdirect-access-external-data to avoid "canonical
PLT entry"/copy relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112

Link: https://github.com/ClangBuiltLinux/linux/issues/1210
Reported-by: Arnd Bergmann <hidden>
Signed-off-by: Fangrui Song <hidden>
---
 arch/x86/kernel/module.c | 1 +
 arch/x86/tools/relocs.c  | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index 34b153cbd4ac..5e9a34b5bd74 100644
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -114,6 +114,7 @@ int apply_relocate(Elf32_Shdr *sechdrs,
 			*location += sym->st_value;
 			break;
 		case R_386_PC32:
+		case R_386_PLT32:
 			/* Add the value, subtract its position */
 			*location += sym->st_value - (uint32_t)location;
 			break;
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index ce7188cbdae5..717e48ca28b6 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -867,6 +867,7 @@ static int do_reloc32(struct section *sec, Elf_Rel *rel, Elf_Sym *sym,
 	case R_386_PC32:
 	case R_386_PC16:
 	case R_386_PC8:
+	case R_386_PLT32:
 		/*
 		 * NONE can be ignored and PC relative relocations don't
 		 * need to be adjusted.
@@ -910,6 +911,7 @@ static int do_reloc_real(struct section *sec, Elf_Rel *rel, Elf_Sym *sym,
 	case R_386_PC32:
 	case R_386_PC16:
 	case R_386_PC8:
+	case R_386_PLT32:
 		/*
 		 * NONE can be ignored and PC relative relocations don't
 		 * need to be adjusted.
-- 
2.29.2.729.g45daf8777d-goog

dileks · 2021-01-07T00:59:02Z

Patch submitted: https://lore.kernel.org/lkml/20210107001739.1321725-1-maskray@google.com/

This is similar to commit b21ebf2 "x86: Treat R_X86_64_PLT32 as R_X86_64_PC32", but for i386. As far as Linux kernel is concerned, R_386_PLT32 can be treated the same as R_386_PC32. R_386_PC32/R_X86_64_PC32 are PC-relative relocation types with the requirement that the symbol address is significant. R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types without the address significance requirement. On x86-64, there is no PIC vs non-PIC PLT distinction and an R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and `call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler. On i386, there are 2 types of PLTs, PIC and non-PIC. Currently the convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC PLT, but R_386_PLT32 is arguably preferable for -fno-pic code as well: this can avoid a "canonical PLT entry" (st_shndx=0, st_value!=0) if the symbol turns out to be defined externally. Latest Clang (since 961f31d8ad14c66829991522d73e14b5a96ff6d4) can use R_386_PLT32 for compiler produced symbols (if we drop -ffreestanding for CONFIG_X86_32, library call optimization can produce newer declarations) and future GCC may use R_386_PLT32 as well if the maintainers agree to adopt an option like -fdirect-access-external-data to avoid "canonical PLT entry"/copy relocations https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 Link: ClangBuiltLinux#1210 Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Fangrui Song <maskray@google.com>

dileks · 2021-01-07T20:41:18Z

Patch v2 submitted: https://lore.kernel.org/lkml/20210107185555.2781221-1-maskray@google.com/

cc #17 Still need to add check_logs.py support once ClangBuiltLinux/linux#1210 is fixed.

nickdesaulniers · 2021-01-28T17:59:34Z

accepted: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=bb73d07148c405c293e576b40af37737faf23a6a

[ Upstream commit bb73d07148c405c293e576b40af37737faf23a6a ] This is similar to commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") but for i386. As far as the kernel is concerned, R_386_PLT32 can be treated the same as R_386_PC32. R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types which can only be used by branches. If the referenced symbol is defined externally, a PLT will be used. R_386_PC32/R_X86_64_PC32 are PC-relative relocation types which can be used by address taking operations and branches. If the referenced symbol is defined externally, a copy relocation/canonical PLT entry will be created in the executable. On x86-64, there is no PIC vs non-PIC PLT distinction and an R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and `call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler. This avoids canonical PLT entries (st_shndx=0, st_value!=0). On i386, there are 2 types of PLTs, PIC and non-PIC. Currently, the GCC/GNU as convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC PLT. Copy relocations/canonical PLT entries are possible ABI issues but GCC/GNU as will likely keep the status quo because (1) the ABI is legacy (2) the change will drop a GNU ld diagnostic for non-default visibility ifunc in shared objects. clang-12 -fno-pic (since [1]) can emit R_386_PLT32 for compiler generated function declarations, because preventing canonical PLT entries is weighed over the rare ifunc diagnostic. Further info for the more interested: ClangBuiltLinux/linux#1210 https://sourceware.org/bugzilla/show_bug.cgi?id=27169 llvm/llvm-project@a084c03 [1] [ bp: Massage commit message. ] Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Fangrui Song <maskray@google.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Link: https://lkml.kernel.org/r/20210127205600.1227437-1-maskray@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit bb73d07148c405c293e576b40af37737faf23a6a ] This is similar to commit b21ebf2 ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") but for i386. As far as the kernel is concerned, R_386_PLT32 can be treated the same as R_386_PC32. R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types which can only be used by branches. If the referenced symbol is defined externally, a PLT will be used. R_386_PC32/R_X86_64_PC32 are PC-relative relocation types which can be used by address taking operations and branches. If the referenced symbol is defined externally, a copy relocation/canonical PLT entry will be created in the executable. On x86-64, there is no PIC vs non-PIC PLT distinction and an R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and `call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler. This avoids canonical PLT entries (st_shndx=0, st_value!=0). On i386, there are 2 types of PLTs, PIC and non-PIC. Currently, the GCC/GNU as convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC PLT. Copy relocations/canonical PLT entries are possible ABI issues but GCC/GNU as will likely keep the status quo because (1) the ABI is legacy (2) the change will drop a GNU ld diagnostic for non-default visibility ifunc in shared objects. clang-12 -fno-pic (since [1]) can emit R_386_PLT32 for compiler generated function declarations, because preventing canonical PLT entries is weighed over the rare ifunc diagnostic. Further info for the more interested: ClangBuiltLinux/linux#1210 https://sourceware.org/bugzilla/show_bug.cgi?id=27169 llvm/llvm-project@a084c03 [1] [ bp: Massage commit message. ] Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Fangrui Song <maskray@google.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Link: https://lkml.kernel.org/r/20210127205600.1227437-1-maskray@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit bb73d07148c405c293e576b40af37737faf23a6a ] This is similar to commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") but for i386. As far as the kernel is concerned, R_386_PLT32 can be treated the same as R_386_PC32. R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types which can only be used by branches. If the referenced symbol is defined externally, a PLT will be used. R_386_PC32/R_X86_64_PC32 are PC-relative relocation types which can be used by address taking operations and branches. If the referenced symbol is defined externally, a copy relocation/canonical PLT entry will be created in the executable. On x86-64, there is no PIC vs non-PIC PLT distinction and an R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and `call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler. This avoids canonical PLT entries (st_shndx=0, st_value!=0). On i386, there are 2 types of PLTs, PIC and non-PIC. Currently, the GCC/GNU as convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC PLT. Copy relocations/canonical PLT entries are possible ABI issues but GCC/GNU as will likely keep the status quo because (1) the ABI is legacy (2) the change will drop a GNU ld diagnostic for non-default visibility ifunc in shared objects. clang-12 -fno-pic (since [1]) can emit R_386_PLT32 for compiler generated function declarations, because preventing canonical PLT entries is weighed over the rare ifunc diagnostic. Further info for the more interested: ClangBuiltLinux/linux#1210 https://sourceware.org/bugzilla/show_bug.cgi?id=27169 llvm/llvm-project@a084c03 [1] [ bp: Massage commit message. ] Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Fangrui Song <maskray@google.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Link: https://lkml.kernel.org/r/20210127205600.1227437-1-maskray@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit bb73d07148c405c293e576b40af37737faf23a6a ] This is similar to commit b21ebf2 ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") but for i386. As far as the kernel is concerned, R_386_PLT32 can be treated the same as R_386_PC32. R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types which can only be used by branches. If the referenced symbol is defined externally, a PLT will be used. R_386_PC32/R_X86_64_PC32 are PC-relative relocation types which can be used by address taking operations and branches. If the referenced symbol is defined externally, a copy relocation/canonical PLT entry will be created in the executable. On x86-64, there is no PIC vs non-PIC PLT distinction and an R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and `call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler. This avoids canonical PLT entries (st_shndx=0, st_value!=0). On i386, there are 2 types of PLTs, PIC and non-PIC. Currently, the GCC/GNU as convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC PLT. Copy relocations/canonical PLT entries are possible ABI issues but GCC/GNU as will likely keep the status quo because (1) the ABI is legacy (2) the change will drop a GNU ld diagnostic for non-default visibility ifunc in shared objects. clang-12 -fno-pic (since [1]) can emit R_386_PLT32 for compiler generated function declarations, because preventing canonical PLT entries is weighed over the rare ifunc diagnostic. Further info for the more interested: ClangBuiltLinux/linux#1210 https://sourceware.org/bugzilla/show_bug.cgi?id=27169 llvm/llvm-project@a084c03 [1] [ bp: Massage commit message. ] Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Fangrui Song <maskray@google.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Link: https://lkml.kernel.org/r/20210127205600.1227437-1-maskray@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit bb73d07148c405c293e576b40af37737faf23a6a ] This is similar to commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") but for i386. As far as the kernel is concerned, R_386_PLT32 can be treated the same as R_386_PC32. R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types which can only be used by branches. If the referenced symbol is defined externally, a PLT will be used. R_386_PC32/R_X86_64_PC32 are PC-relative relocation types which can be used by address taking operations and branches. If the referenced symbol is defined externally, a copy relocation/canonical PLT entry will be created in the executable. On x86-64, there is no PIC vs non-PIC PLT distinction and an R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and `call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler. This avoids canonical PLT entries (st_shndx=0, st_value!=0). On i386, there are 2 types of PLTs, PIC and non-PIC. Currently, the GCC/GNU as convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC PLT. Copy relocations/canonical PLT entries are possible ABI issues but GCC/GNU as will likely keep the status quo because (1) the ABI is legacy (2) the change will drop a GNU ld diagnostic for non-default visibility ifunc in shared objects. clang-12 -fno-pic (since [1]) can emit R_386_PLT32 for compiler generated function declarations, because preventing canonical PLT entries is weighed over the rare ifunc diagnostic. Further info for the more interested: ClangBuiltLinux/linux#1210 https://sourceware.org/bugzilla/show_bug.cgi?id=27169 llvm/llvm-project@a084c03 [1] [ bp: Massage commit message. ] Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Fangrui Song <maskray@google.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Link: https://lkml.kernel.org/r/20210127205600.1227437-1-maskray@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit bb73d07148c405c293e576b40af37737faf23a6a ] This is similar to commit b21ebf2 ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") but for i386. As far as the kernel is concerned, R_386_PLT32 can be treated the same as R_386_PC32. R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types which can only be used by branches. If the referenced symbol is defined externally, a PLT will be used. R_386_PC32/R_X86_64_PC32 are PC-relative relocation types which can be used by address taking operations and branches. If the referenced symbol is defined externally, a copy relocation/canonical PLT entry will be created in the executable. On x86-64, there is no PIC vs non-PIC PLT distinction and an R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and `call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler. This avoids canonical PLT entries (st_shndx=0, st_value!=0). On i386, there are 2 types of PLTs, PIC and non-PIC. Currently, the GCC/GNU as convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC PLT. Copy relocations/canonical PLT entries are possible ABI issues but GCC/GNU as will likely keep the status quo because (1) the ABI is legacy (2) the change will drop a GNU ld diagnostic for non-default visibility ifunc in shared objects. clang-12 -fno-pic (since [1]) can emit R_386_PLT32 for compiler generated function declarations, because preventing canonical PLT entries is weighed over the rare ifunc diagnostic. Further info for the more interested: ClangBuiltLinux/linux#1210 https://sourceware.org/bugzilla/show_bug.cgi?id=27169 llvm/llvm-project@a084c03 [1] [ bp: Massage commit message. ] Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Fangrui Song <maskray@google.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Link: https://lkml.kernel.org/r/20210127205600.1227437-1-maskray@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit bb73d07148c405c293e576b40af37737faf23a6a ] This is similar to commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") but for i386. As far as the kernel is concerned, R_386_PLT32 can be treated the same as R_386_PC32. R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types which can only be used by branches. If the referenced symbol is defined externally, a PLT will be used. R_386_PC32/R_X86_64_PC32 are PC-relative relocation types which can be used by address taking operations and branches. If the referenced symbol is defined externally, a copy relocation/canonical PLT entry will be created in the executable. On x86-64, there is no PIC vs non-PIC PLT distinction and an R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and `call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler. This avoids canonical PLT entries (st_shndx=0, st_value!=0). On i386, there are 2 types of PLTs, PIC and non-PIC. Currently, the GCC/GNU as convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC PLT. Copy relocations/canonical PLT entries are possible ABI issues but GCC/GNU as will likely keep the status quo because (1) the ABI is legacy (2) the change will drop a GNU ld diagnostic for non-default visibility ifunc in shared objects. clang-12 -fno-pic (since [1]) can emit R_386_PLT32 for compiler generated function declarations, because preventing canonical PLT entries is weighed over the rare ifunc diagnostic. Further info for the more interested: ClangBuiltLinux/linux#1210 https://sourceware.org/bugzilla/show_bug.cgi?id=27169 llvm/llvm-project@a084c03 [1] [ bp: Massage commit message. ] Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Fangrui Song <maskray@google.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Link: https://lkml.kernel.org/r/20210127205600.1227437-1-maskray@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>

nickdesaulniers added [BUG] Untriaged Something isn't working [ARCH] x86 This bug impacts ARCH=i386 labels Dec 7, 2020

MaskRay self-assigned this Jan 6, 2021

dileks added the [PATCH] Submitted A patch has been submitted for review label Jan 7, 2021

nathanchance mentioned this issue Jan 9, 2021

32-bit x86 should be using i386 for tuxbuild ClangBuiltLinux/continuous-integration2#17

Closed

nickdesaulniers mentioned this issue Jan 11, 2021

Unknown symbol _GLOBAL_OFFSET_TABLE_ loading kernel modules #1250

Closed

nathanchance added this to the LLVM 12 milestone Jan 14, 2021

nickdesaulniers added a commit to ClangBuiltLinux/continuous-integration2 that referenced this issue Jan 21, 2021

i386 support

0473728

cc #17 Still need to add check_logs.py support once ClangBuiltLinux/linux#1210 is fixed.

nickdesaulniers mentioned this issue Jan 21, 2021

I386 ClangBuiltLinux/continuous-integration2#33

Merged

nickdesaulniers added a commit to ClangBuiltLinux/continuous-integration2 that referenced this issue Jan 21, 2021

i386 support

5a5aa0d

cc #17 Still need to add check_logs.py support once ClangBuiltLinux/linux#1210 is fixed.

nickdesaulniers added [BUG] linux A bug that should be fixed in the mainline kernel. [PATCH] Accepted A submitted patch has been accepted upstream and removed [BUG] Untriaged Something isn't working labels Jan 28, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

clang-12: Unsupported relocation type: R_386_PLT32 #1210

clang-12: Unsupported relocation type: R_386_PLT32 #1210

arndb commented Dec 7, 2020

nickdesaulniers commented Dec 7, 2020

nivedita76 commented Dec 7, 2020

nivedita76 commented Dec 7, 2020 •

edited by nathanchance

Loading

arndb commented Dec 7, 2020

MaskRay commented Dec 8, 2020 •

edited by nathanchance

Loading

arndb commented Dec 8, 2020

arndb commented Dec 8, 2020

MaskRay commented Dec 8, 2020 •

edited

Loading

nivedita76 commented Dec 8, 2020

nickdesaulniers commented Dec 8, 2020

MaskRay commented Jan 6, 2021

MaskRay commented Jan 6, 2021 •

edited

Loading

dileks commented Jan 7, 2021

dileks commented Jan 7, 2021

nickdesaulniers commented Jan 28, 2021

clang-12: Unsupported relocation type: R_386_PLT32 #1210

clang-12: Unsupported relocation type: R_386_PLT32 #1210

Comments

arndb commented Dec 7, 2020

nickdesaulniers commented Dec 7, 2020

nivedita76 commented Dec 7, 2020

nivedita76 commented Dec 7, 2020 • edited by nathanchance Loading

arndb commented Dec 7, 2020

MaskRay commented Dec 8, 2020 • edited by nathanchance Loading

arndb commented Dec 8, 2020

arndb commented Dec 8, 2020

MaskRay commented Dec 8, 2020 • edited Loading

nivedita76 commented Dec 8, 2020

nickdesaulniers commented Dec 8, 2020

MaskRay commented Jan 6, 2021

MaskRay commented Jan 6, 2021 • edited Loading

dileks commented Jan 7, 2021

dileks commented Jan 7, 2021

nickdesaulniers commented Jan 28, 2021

nivedita76 commented Dec 7, 2020 •

edited by nathanchance

Loading

MaskRay commented Dec 8, 2020 •

edited by nathanchance

Loading

MaskRay commented Dec 8, 2020 •

edited

Loading

MaskRay commented Jan 6, 2021 •

edited

Loading