https://sourceware.org/bugzilla/show_bug.cgi?id=26141
--- Comment #6 from Jason A. Donenfeld <jason at zx2c4 dot com> --- (In reply to Nick Clifton from comment #4) > Hi Jason, > > Thanks for the test case. There was a small problem with it, in that > it deletes all of the temporary files at the end, including the newly > built wireguard.ko, which makes it hard to investigate. Whoops. Was my expectation that you'd want to modify that, of course. :) > > Anyway I was able to capture the wireguard.ko file and I checked - > the R_ARM_THM_JUMP11 reloc is certainly there, but it is also valid. > The relocation can be processed to produce a valid branch instruction. > > > > The kernel module loader then sees R_ARM_THM_JUMP11 and refuses to load it, > > because it doesn't do JUMP11 relocations. > > This sounds to me like a kernel bug. Why does it not support the > R_ARM_THM_JUMP11 relocation ? It supports other relocations, right ? It's not a kernel bug. See the comment in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/Kconfig?id=5e857ce6eae7ca21b2055cca4885545e29228fe2#n1431 } Various binutils versions can resolve Thumb-2 branches to } locally-defined, preemptible global symbols as short-range "b.n" } branch instructions. } } This is a problem, because there's no guarantee the final } destination of the symbol, or any candidate locations for a } trampoline, are within range of the branch. For this reason, the } kernel does not support fixing up the R_ARM_THM_JUMP11 (102) } relocation in modules at all, and it makes little sense to add } support. } } The symptom is that the kernel fails with an "unsupported } relocation" error when loading some modules. The commit goes onto describe a workaround, which is no longer necessary, as binutils has been fixed. At least until this new bug: } Until fixed tools are available, passing } -fno-optimize-sibling-calls to gcc should prevent gcc generating } code which hits this problem, at the cost of a bit of extra runtime } stack usage in some cases. } } The problem is described in more detail at: } https://bugs.launchpad.net/binutils-linaro/+bug/725126 } } Only Thumb-2 kernels are affected. } } Unless you are sure your tools don't have this problem, say Y. It's now possible to say N there, except if you use -fvisibility=hidden, which is what I ran into. > I am inclined to consider this as not being a bug. Given that you > have a workaround, and, to my mind, the real culprit is the kernel. > Nevertheless I can appreciate that fixing the kernel might be > difficult, so I can see the appeal of an assembler based solution. I don't know how to decide whose bug this is, but at least the last time it came up, it was considered a binutils deficiency that got fixed, so I would assume similar reason applies to this bug too. > As it happens the assembler already has some special case code to > cover other relocations not supported by the kernel, so adding one > more should not hurt. Thus I am uploading a patch for you to test. > Please could you try it out and let me know if it works ? Oh, great, thanks a lot. I'll give it a try and will let you know. -- You are receiving this mail because: You are on the CC list for the bug.
