On Mon, May 20, 2019 at 05:48:52PM +0930, Alan Modra wrote: > On Mon, May 20, 2019 at 02:55:33AM -0500, Segher Boessenkool wrote: > > On Mon, May 20, 2019 at 04:19:54PM +0930, Alan Modra wrote: > > > On Thu, May 16, 2019 at 05:52:42PM -0500, Segher Boessenkool wrote: > > > > I wonder if you have found a bug in the compiler after all. Most things > > > > are supposed to work without the linker/loader having to do special > > > > things; e.g. using the global entry point should always work, using the > > > > local entry point is just an optimisation. > > > > > > That isn't true for direct calls. If using the global entry point, > > > the linker must provide stub code to load up r12 with the global entry > > > address and modify the nop after the bl. The linker must also adjust > > > calls using the local entry point; the call instruction (and > > > relocation) specify the function symbol not the function plus local > > > entry offset. > > > > > > So I don't think there is any compiler bug here, just a broken kernel > > > module loader. Incidentally, if thunks are broken then it's very > > > likely local function calls are broken too. > > > > The ABI says > > > > "When a linker causes control to transfer to a global entry point, it > > must insert a glue code sequence that loads r12 with the global > > entry-point address. Code at the global entry point can assume that > > register r12 points to the GEP." > > > > But in the testcase the jump *already* was to the global entry point: > > So? We never add the local entry offset to the call assembly.
I guess I read that wrong then -- I read it as "when a linker changes some jump so that it goes to a global entry point". But it means it needs to make a stub for every global entry point that is used? Segher
