[RFC] [PR 68191] s390: Add -fsplit-stack support.

Marcin Kościelnicki koriakin@0x04.net
Mon Jan 4 07:35:00 GMT 2016


On 03/01/16 04:20, Ian Lance Taylor wrote:
> On Sat, Jan 2, 2016 at 11:16 AM, Marcin Kościelnicki <koriakin@0x04.net> wrote:
>>
>> The differences start in the __morestack calling convention.  Basically,
>> since pushing things on stuck is unwieldy and there's only one free
>> register (%r0 could be used for static chain, %r2-%r6 contain arguments,
>> %r6-%r15 are callee-saved), I stuff the parameters somewhere in .rodata
>> or .text section, and pass the address of the parameter block in %r1.
>> The parameter block also contains a (position-relative) address that
>> __morestack should jump to (x86 just mangles the return address from
>> __morestack to compute that).  On zSeries CPUs, the parameter block
>> is stuffed somewhere in .rodata, its address loaded to %r1 by larl
>> instruction, and __morestack is sibling-called by jg instruction.
>
> Does that work in a multi-threaded program if two different threads
> are calling the same function at the same time and both threads need
> to split the stack?

For a few more details - __morestack takes three parameters:

- function's frame size (initial frame size if it happens to use alloca 
or VLAs later)
- size function's arguments on stack (not including varargs, if any)
- a pointer to the label where execution should be continued after stack 
is allocated

All three are per-function consts.  The first two are computed by the 
compiler (though frame size can be mangled by linker for functions 
calling non-split-stack code), and the third by the linker (since it 
involves relocation).  Since the parameters are known at link time, 
they're put in a per-function block in .rodata or .text and never 
change.  Simultanous access to that area is not a problem, since it's 
never written.

Marcin Kościelnicki

>
> Ian
>



More information about the Gcc-patches mailing list