Perry Smith writes:
On Nov 29, 2006, at 4:19 AM, Andrew Haley wrote:
Perry Smith writes:
No, I did not. I thought it would be too big a task and I'm
willing to put a try/catch after the stack has been changed so the
unwind does not need to go through this. This may be naive. (See
more below).
You'll need unwinder data, sooner or later. But let's leave it for
later, it's not strictly relevant to what you need now.
But in optimized code, the compiler does not load r1 with r1(0).
It assumes that r1 has not changed, and it knows the size of the
stack frame, it just adds the size of the stack frame to r1. This
will be the same address if r1 has not been changed.
Right.
It seems like (but I may be wrong), even with the DWARF unwinder
information, the compiler will still produce the code that adds the
size of the stack from to r1 to get r1 to point to the previous
stack frame instead of loading r1 with r1 (0).
Sure, but why would it matter? Your newStack routine should do
something like
newStack:
save caller registers somewhere
load new stack and frame pointer
call <foo> -- whatever it is you want to run on the new stack
restore caller registers, including stack and frame pointer
return
so it should not metter how the caller of newStack uses its stack
frame or what foo does. As long as you conform to the ABI you'll be
OK.