Hello. Not really a problem but might become an issue when updating system compiler. Trying to compile emulators/virtualbox-ose-kmod I found out that produced binaries can't be loaded as a kernel modules: Sep 18 16:36:31 limbo kernel: kldload: unexpected relocation type 4 Sep 18 16:36:31 limbo kernel: kldload: unexpected relocation type 4 Sep 18 16:36:31 limbo kernel: kldload: unexpected relocation type 4 Sep 18 16:36:31 limbo kernel: kldload: unexpected relocation type 4 ... Sep 18 16:36:31 limbo kernel: kldload: unexpected relocation type 4 Sep 18 16:36:31 limbo kernel: kldload: unexpected relocation type 4 Sep 18 16:36:31 limbo kernel: kldload: unexpected relocation type 4 Sep 18 16:36:31 limbo kernel: link_elf_obj: symbol bzero undefined Sep 18 16:36:31 limbo kernel: linker_load_file: Unsupported file type Compiling said modules with system compiler or clang60 results in a working kernel module. Thank you.
The question here is: is llvm70 emitting an inappropriate relocation or is the kernel missing support for a reasonable relocation that we've not needed before?
Relocation type 4 is apparently R_X86_64_PLT32, and I see lots of those in vboxdrv.ko, indeed: Relocation section '.rela.text' at offset 0x4ba38 contains 3429 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000000023 000000030000000b R_X86_64_32S 0000000000000000 .rodata.str1.1 + 17a2 000000000000002a 000000030000000b R_X86_64_32S 0000000000000000 .rodata.str1.1 + 17a6 0000000000000037 000000020000000b R_X86_64_32S 0000000000000000 .rodata + 510 0000000000000042 000001fa00000004 R_X86_64_PLT32 0000000000011a90 RTLogCreate - 4 0000000000000053 000001f000000004 R_X86_64_PLT32 0000000000015680 RTLogRelSetDefaultInstance - 4 0000000000000069 000000030000000b R_X86_64_32S 0000000000000000 .rodata.str1.1 + 17b7 0000000000000072 000001be00000004 R_X86_64_PLT32 000000000000fb10 SUPR0Printf - 4 000000000000008c 0000038f00000004 R_X86_64_PLT32 0000000000000000 memset - 4 00000000000000f0 000000030000000b R_X86_64_32S 0000000000000000 .rodata.str1.1 + 17e2 00000000000000f9 0000016c00000004 R_X86_64_PLT32 000000000002bab0 RTSpinlockCreate - 4 000000000000010d 000000030000000b R_X86_64_32S 0000000000000000 .rodata.str1.1 + 17ef 0000000000000115 0000016c00000004 R_X86_64_PLT32 000000000002bab0 RTSpinlockCreate - 4 0000000000000129 000000030000000b R_X86_64_32S 0000000000000000 .rodata.str1.1 + 17f9 0000000000000131 0000016c00000004 R_X86_64_PLT32 000000000002bab0 RTSpinlockCreate - 4 0000000000000142 000000cb00000004 R_X86_64_PLT32 000000000002b540 RTSemFastMutexCreate - 4 0000000000000153 000000cb00000004 R_X86_64_PLT32 000000000002b540 RTSemFastMutexCreate - 4 000000000000016e 000000cb00000004 R_X86_64_PLT32 000000000002b540 RTSemFastMutexCreate - 4 0000000000000186 000000cb00000004 R_X86_64_PLT32 000000000002b540 RTSemFastMutexCreate - 4 0000000000000196 000001e300000004 R_X86_64_PLT32 0000000000007390 supdrvGipCreate - 4 00000000000001a6 000001a700000004 R_X86_64_PLT32 000000000000eb70 supdrvTracerInit - 4 00000000000001d2 000000060000000b R_X86_64_32S 0000000000000000 .data + 40 00000000000001e4 000000060000000b R_X86_64_32S 0000000000000000 .data + 68 00000000000001f2 000000060000000b R_X86_64_32S 0000000000000000 .data + 90 0000000000000200 000000060000000b R_X86_64_32S 0000000000000000 .data + b8 000000000000020e 000000060000000b R_X86_64_32S 0000000000000000 .data + e0 000000000000021c 000000060000000b R_X86_64_32S 0000000000000000 .data + 108 [...] When linking it with lld 6, I only see these types: R_X86_64_32S R_X86_64_64 R_X86_64_PC32 No idea what is causing this, or why R_X86_64_PLT32 relocations would be considered bad by the kernel loader, yet.
Likely due to https://bugs.llvm.org/show_bug.cgi?id=36370 ('We should produce a R_X86_64_PLT32 for "call foo"'), committed in https://reviews.llvm.org/rL325569 ('[llvm-mc] - Produce R_X86_64_PLT32 for "call/jmp foo"').
Hm, base r309748 added support for R_X86_64_PLT32, but this only appears in 12-CURRENT, it was never MFC'd, for some reason. Volodymyr, you didn't specify the version of your base system for this bug, but I assume it is 11.x, then? Anybody have objections against merging base r309748 to stable/11 (and maybe even stable/10)?
No objection to MFCing support (as well as dependencies, if any)
A commit references this bug: Author: dim Date: Tue Sep 18 20:46:57 UTC 2018 New revision: 338756 URL: https://svnweb.freebsd.org/changeset/base/338756 Log: MFC r309748 (by glebius): Treat R_X86_64_PLT32 relocs as R_X86_64_PC32. If we load a binary that is designed to be a library, it produces relocatable code via assembler directives in the assembly itself (rather than compiler options). This emits R_X86_64_PLT32 relocations, which are not handled by the kernel linker. Submitted by: gallatin Reviewed by: kib PR: 231451 Changes: _U stable/10/ stable/10/sys/amd64/amd64/elf_machdep.c _U stable/11/ stable/11/sys/amd64/amd64/elf_machdep.c _U stable/8/ _U stable/8/sys/ _U stable/8/sys/amd64/ stable/8/sys/amd64/amd64/elf_machdep.c _U stable/9/ _U stable/9/sys/ stable/9/sys/amd64/amd64/elf_machdep.c
(In reply to Dimitry Andric from comment #4) Yep, I'm on 11-STABLE.
Thank you. Works like a charm now.