Michael, > On Wed, 2012-05-30 at 16:33 +0200, Steffen Rumler wrote: > > I've found the following root cause: > > > > (6) Unfortunately, the trampoline code (do_plt_call()) is using > register r11 to setup the jump. > > It looks like the prologue and epilogue are using also the > register r11, in order to point to the previous stack frame. > > This is a conflict !!! The trampoline code is damaging the > content of r11. > > Hi Steffen, > > Great bug report! > > I can't quite work out what the standards say, the versions I'm looking > at are probably old anyway.
The ABI supplement from https://www.power.org/resources/downloads/ is explicit about r11 being a requirement for the statically lined save/restore functions in section 3.3.4 on page 59. This means that any trampoline code must not ever use r11 or it can't be used to get to such save/restore functions safely from far away. Unfortunately the same doc and predecessors show r11 in all basic examples for PLT/trampoline code AFAICS, which is likely why all trampoline code uses r11 in any known case. I would guess that it was never envisioned that compiler generated code would be in a different section than save/restore functions, i.e., the Linux module "__init" assumptions for Power break the ABI. Or does the ABI break the __init concept?! Using r12 in the trampoline seems to be the obvious solution for module loading. But what about other code loading done? If, e.g., a user runs any app from bash it gets loaded and relocated and trampolines might get set up somehow. Wouldn't we have to find fix ANY trampoline code generator remotely related to a basic Power Architecture Linux? Or is it a basic assumption for anything but modules that compiler generated code may never ever be outside the .text section? I am not sure that would be a safe assumption. Isn't this problem going beyond just module loading for Power Architecture Linux? Regards, Heinz _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
