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.kreb...@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 -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com