This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [split] Add x86 support
- From: Richard Henderson <rth at redhat dot com>
- To: Ross Ridge <rridge at csclub dot uwaterloo dot ca>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 28 Sep 2009 14:26:07 -0700
- Subject: Re: [split] Add x86 support
- References: <20090926200824.8970D73F82@caffeine.csclub.uwaterloo.ca>
On 09/26/2009 01:08 PM, Ross Ridge wrote:
Ross Ridge writes:
You still seem to invalidating the return stack. Because each call
doesn't have a corresponsing return, the ret instruction at the end
of __morestack will be mispredicted to return to where __morestack
was called.
Ian Lance Taylor writes:
It seems to me that each call does have a corresponding return. But it's
also quite possible that I misunderstand how the return predictor works.
Well, unless I'm missing something the call/return sequence in your
patch goes like this (for a function named "foo" called by "bar"):
bar calls foo
foo calls __morestack
__morestack calls back into foo
foo returns to __morestack (as predicted)
__morestack returns to bar (but is predicted to return to foo)
He's right.
Somethine else I thought of: you're not handling stdcall functions,
which require popping the stack on return from foo.
All of which makes me wonder if it would be easier to support split
stacks within foo directly. I know this conflicts with your goal of
generating split-stack thunk-like objects directly from the linker,
but I don't see that you are being given enough information about the
target function's abi to do that in general.
What if you were to treat the split stack problem more like the stack
realignment problem? I could imagine something like
foo:
push %rbp # set up backchain
movq %rsp, %rbp
movq $1000, %r10 # required stack space
call __morestack
# At this point we're either on the old stack with 1000
# bytes of space remaining, or on a new stack.
As with stack realignment, arguments are accessed via %rbp, while
local variables are accessed via %rsp. One can also imagine a
__morestack_aligned that combines aligning the stack frame with the
space check.
As with stack realignment, if foo uses alloca, then we have to use
a separate register to access the arguments. But that's more or
less a solved problem as well.
Since you mention that you don't actually have to free the stack
on the way out (to support longjmp), then it would seem that you
also don't have to inject that extra stack frame from __morestack
to release the new stack. Failing that, you can always modify
the function epilogue to release the stack somehow (notice CFA
value not within the "current" stack perhaps?).
r~