On Fri, Jun 01, 2012 at 11:33:37AM +0000, Wrobel Heinz-R39252 wrote:
I believe that the basic premise is that you should provide a directly
reachable copy of the save/rstore functions, even if this means that
you need several copies of the functions.
I just fixed a very similar problem with grub2 in fact. It was using r0
and trashing the saved LR that way.
The real fix is indeed to statically link those gcc "helpers", we
shouldn't generate things like cross-module calls inside function prologs
and epilogues, when stackframes aren't even guaranteed to be reliable.
However, in the grub2 case, it was easier to just use r12 :-)
For not just the module loading case, I believe r12 is the only real solution
now. I checked one debugger capable of doing ELF download. It also uses r12 for
trampoline code. I am guessing for the reason that prompted this discussion.
I disagree. Look carefully at Be's answer: cross-module calls
are intrinsically dangerous when stack frames are in a transient
state.
Without r12 we'd have to change standard libraries to automagically link in gcc
helpers for any conceivable non-.text section, which I am not sure is feasible.
How would you write section independent helper functions which link to any
section needing them?!
I don't thnk that it is tha bad: the helpers should be linked to the default
.text section
when needed, typically the init code and so on are mapped within the reach of
that
section (otherwise you'll end up with the linker complaining that it finds
overflowing
branch offsets between .text and .init.text).
Asking users to create their own section specific copy of helper functions is
definitely not portable if the module or other code is not architecture
dependent.
Well, it automagically works on 64 bit. There is is performed by magic built
into the linker.
It is a normal gcc feature that you can assign specific code to non-.text
sections and it is not documented that it may crash depending on the OS arch
the ELF is built for, so asking for a Power Architecture specific change on
tool libs to make Power Architecture Linux happy seems a bit much to ask.
Once again I disagree.
Using r12 in any Linux related trampoline code seems a reachable goal, and it
would eliminate the conflict to the ABI.
There is no conflict to the ABI. These functions are supposed to be directly
reachable from whatever code
section may need them.
Now I have a question: how did you get the need for this?
None of my kernels uses them:
- if I compile with -O2, the compiler simply expands epilogue and prologue to
series of lwz and stw
- if I compile with -Os, the compiler generates lmw/stmw which give the
smallest possible cache footprint
Neither did I find a single reference to these functions in several systems
that I grepped for.
Regards,
Gabriel
Hi,
how should we continue here ?
There is the kernel panic, I've described.
Technically, there is an conflict between the code generated by the compiler
and the loader in module_32.c, at least by using -Os.
Because the prologue/epilogue is part of the .text and init_module() is part of
.init.text (in the case __init is applied, as usual),
a directly reachable call is not always possible.
Thanks
Steffen
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
