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? (Still true of clang 6.)

[Mark Millard]

[Notes on clang 6 properties for this. Also note: newer Email
address than the original.]

On 2017-Dec-29, at 4:18 PM, Mark Millard <markmi at dsl-only.net> wrote:

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

I finally did some updating of part of my
FreeBSD environment, jumping something like
2000 revision numbers . . .

Under head -r329542 and its clang 6 there is still a
"Relocation section with addend (.rela.plt)" that
uses R_PPC64_JMP_SLOT r_types.

(This is using devel/powerpc64-binutils .)

(There was and is some .rela.dyn and
R_PPC64_RELATIVE/R_PPC64_ADDR64 use
as well.)

So: 6 is like 5.0.1 for this issue.

> 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

Under head -r329542 devel/powerpc64-gcc there is
no use of .rela.plt or R_PPC64_JMP_SLOT: Just
.rela.dyn and R_PPC64_RELATIVE/R_PPC64_ADDR64
use.

(This is using devel/powerpc64-binutils .)

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

I have not actually tried the modern builds
on a old PowerMac G5 yet: other things took
up time. Also the USB devmatch issues are a
worry since I have no alternatives to
directly connected USB keyboards, mice (and
possibly more) if I end up unable to connect
over the local network for some reason.

But I've not noticed anything go by that
indicated adding support for R_PPC64_JMP_SLOT
or .rela.plt in filemon.ko or other such .ko's.
So I only expect dynamic module loading to work
for the devel/powerpc64-gcc based kernel.

(I still build-in two(?) extra .ko's to avoid the
loading issue for them if I play with the clang
based kernel. One of them is filemon.ko .)

===
Mark Millard
marklmi at yahoo.com
( markmi at dsl-only.net is
going away in 2018-Feb, late)