[I experiment with system-clang as a means of building FreeBSD for powerpc64 (and powerpc).] [Note: -r326192 and its clang 5.0.0 context did not have this issue. 5.0.1 may have added to the range of relocation handling needed for dynamically loaded kernel modules.] When the powerpc64 kernel is (cross) built via -r327075 and its clang (5.0.1), the kernel produced crashes when dynamically loading kernel modules (say via kldload or via geom_label_load="YES" in /boot/loader.conf ). By contrast, the same sources used to cross build via devel/powerpc64-xtoolchain-gcc produces a kernel for which the same world (not updated) dynamically loads kernel modules just fine (including via kldload or via geom_label_load="YES" in /boot/loader.conf ). Both cases are using: devel/powerpc64-binutils because (A) lld does not work for powerpc64 built via clang last I knew and (B) the system binutils do not work for that kind of context either. I'll note that for TARGET_ARCH=powerpc clang 5 and the system binutils do not work together. There is no devel/powerpc-binutils and last I knew lld did not work for powerpc yet. So I've not tested a clang based kernel for it. A gcc 4.2.1 based kernel does not have the problem.
(In reply to Mark Millard from comment #0) The difference in the likes of filemon.ko between system clang 5.0.1 and evel/powerpc64-xtoolchain-gcc is. . . clang 5.0.1: Relocation section with addend (.rela.plt): r_offset r_info r_type st_value st_name + r_addend 000000014480 000300000015 R_PPC64_JMP_SLOT 0000000000000000 copyinstr + 0 000000014488 000400000015 R_PPC64_JMP_SLOT 0000000000000000 devfs_set_cdevpriv + 0 . . . devel/powerpc64-xtoolchain-gcc: Relocation section with addend (.rela.dyn): r_offset r_info r_type st_value st_name + r_addend 0000000145c0 000000000016 R_PPC64_RELATIVE 0000000000000000 + 40d0 0000000145e0 000000000016 R_PPC64_RELATIVE 0000000000000000 + 145b0 . . . 000000014408 000600000026 R_PPC64_ADDR64 0000000000000000 sysent + 0 000000014410 001100000026 R_PPC64_ADDR64 0000000000000000 freebsd32_sysent + 0
At least for the following combination, this was no longer a problem (but clang is still using R_PPC64_JMP_SLOT in .ko files so it was apparently FreeBSD that changed): # uname -apKU FreeBSD FBSDG5L 13.0-CURRENT FreeBSD 13.0-CURRENT #8 r345758M: Sun Mar 31 19:43:35 PDT 2019 markmi@FBSDFSSD:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG powerpc powerpc64 1300017 1300017 amd64->powerpc64 cross-built with system-clang and devel/powerpc64-binutils using WITH_LLVM_LIBUNWIND= (patched) and WITHOUT_LIB32= . Various other patches/workarounds for other issues are present, unrelated to R_PPC64_JMP_SLOT use in .ko files. (I exierment with using more modern tool-chains to build for powerpc64 and powerpc.) The system is an old PowerMac G5 (2 sockets, 2 cores per). I was able to comment out my prior inclusion of filemon and mac_ntpd in the kernel, so I now have: # kldstat Id Refs Address Size Name 1 6 0xc000000000100000 1927578 kernel 2 1 0xe00000008fcd2000 12000 mac_ntpd.ko 3 1 0xe00000008efda000 15000 filemon.ko I've no clue just when the status changed.