This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] s390: Add -fsplit-stack support
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: koriakin at 0x04 dot net (Marcin KoÅcielnicki)
- Cc: krebbel at linux dot vnet dot ibm dot com, gcc-patches at gcc dot gnu dot org
- Date: Thu, 4 Feb 2016 16:06:39 +0100 (CET)
- Subject: Re: [PATCH] s390: Add -fsplit-stack support
- Authentication-results: sourceware.org; auth=none
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
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com