[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