[Bug gas/26141] -fvisibility=hidden generates JUMP11 relocations on ARM

[jason at zx2c4 dot com]

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.