Marcin KoÃâcielnicki wrote:
Ugh. I take that back. For -fPIC, the load-address sequence is:
larl %r1,f@GOTENT
lg %r2,0(%r1)
br %r14
This is correct.
And (sibling) call sequence is:
larl %r1,f@GOTENT
lg %r1,0(%r1)
br %r1
Oops. That is actually a GCC bug. The sibcall sequence really must be:
jg f@PLT
This is a real bug since it forces non-lazy symbol resolution for f
just because the compiler chose those use a sibcall optimization;
that's not supposed to happen.
It seems this bug was accidentally introduced here:
2010-04-20 Andreas Krebbel <Andreas.Krebbel@de.ibm.com>
PR target/43635
* config/s390/s390.c (s390_emit_call): Turn direct into indirect
calls for -fpic -m31 if they have been sibcall optimized.
since the patch doesn't check for TARGET_64BIT ...
Andreas, can you have a look?
It seems there's no proper way to recognize a call vs a load address -
so we can either go with emitting the marker, or have the same problem
as on ppc.
So - how much should we care?
I think we should fix that bug. That won't help for existing objects,
but those don't use split stack either, so that shouldn't matter.
If we fix that bug before (or at the same time as) adding split-stack
support, the linker will still be able to distigunish function pointer
loads from calls (including sibcalls) on all objects using split stack.
Bye,
Ulrich