Is the clang 5.0.1 use of .rela.plt and R_PPC64_JMP_SLOT for kernel modules a llvm issue? Just a FreeBSD one?

[Mark Millard]

I've not been able to figure out if I should submit something
into llvm's bugzilla for the powerpc64 switching to .rela.plt
and R_PPC64_JMP_SLOT for kernel modules from the earlier
.rela.dyn and R/PPC64_RELATIVE and R_PPC64_ADDR64 for kernel
modules. (I do not know if powerpc would also have the issue
since other things have been stopping that build for a long
time.)

Do one or more of you have a clue?

Reminder:


I have submitted FreeBSD bugzilla 224561 for the issue.

The difference in the likes of filemon.ko
produced by system clang 5.0.1 vs.
devel/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
. . .

vs.

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

Apparently R_PPC64_JMP_SLOT is mishandled
and does not explicitly lead to rejection
of the attempted dynamic load.

It might be an issue if .rela.plt and
R_PPC64_JMP_SLOT should even be generated
instead of .rela.dyn and R_PPC64_RELATIVE
and R_PPC64_ADDR64.

===
Mark Millard
markmi at dsl-only.net