[PATCH] s390: Add -fsplit-stack support

[Marcin Kościelnicki]

>>
>> The second issue I'm still not sure about is the magic nop marker
>> for frameless functions.  In an earlier mail you wrote:
>>
>>> Both currently supported
>>> architectures always emit split-stack code on every function.
>>
>> At least for rs6000 this doesn't appear to be true; in
>> rs6000_expand_split_stack_prologue we have:
>>
>>    if (!info->push_p)
>>      return;
>>
>> so it does nothing for frameless routines.
>>
>> Now on i386 we do indeed generate code for frameless routines;
>> in fact, the *same* full stack check is generated as for any
>> other routine.  Now I'm wondering: is there are reason why
>> this check would be necessary (and there's simply a bug in
>> the rs6000 implementation)?  Then we obviously should do the
>> same on s390.
>
> Try that on powerpc64(le):
>
> $ cat a.c
> #include <stdio.h>
>
> void f(void) {
> }
>
> typedef void (*fptr)(void);
>
> fptr g(void);
>
> int main() {
>          printf("%p\n", g());
> }
>
> $ cat b.c
> void f(void);
>
> typedef void (*fptr)(void);
>
> fptr g(void) {
>          return f;
> }
>
> $ gcc -O3 -fsplit-stack -c b.c
> $ gcc -O3 -c a.c
> $ gcc a.o b.o -fuse-ld=gold
>
> I don't have a recent enough gcc for powerpc, but from what I've seen in
> the code, this should explode with a linker error.
>
> Of course, mixing split-stack and non-split-stack code when function
> pointers are involved is sketchy anyway, so what's one more bug...
>
> That said, for s390, we can avoid the above problem by checking the
> relocation in gold now that ESA paths are gone - for direct function
> calls (the only ones we care about), we should be seeing a relocation in
> brasl.  So I'll remove the nopmark thing and add proper recognition in
> gold.

Ugh. I take that back.  For -fPIC, the load-address sequence is:

         larl    %r1,f@GOTENT
         lg      %r2,0(%r1)
         br      %r14

And (sibling) call sequence is:

         larl    %r1,f@GOTENT
         lg      %r1,0(%r1)
         br      %r1

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?

>
>>
>> On the other hand, if rs6000 works fine *without* any code
>> in frameless routines, why wouldn't that work for s390 too?
>>
>> Emitting a nop (that is always executed) still looks weird to me.
>>
>>
>> Bye,
>> Ulrich
>>
>