This is the mail archive of the
mailing list for the GCC project.
Re: alloca attribute?
On Nov 29, 2006, at 8:24 AM, Andrew Haley wrote:
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
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.
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
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
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
Ahh... I think I see your confusion. newStack does not call <foo>.
I could do that and it
would probably be safer, easier. But sometimes newStack would need
to call foo(a) and
other times it would need to call foo(a, b), etc. I thought about
using varargs so that
any foo that is called must take a varargs argument. That approach,
doable but imposes several restriction.
But then I hit upon this other idea (which may suck). newStack
simply mucks with
the stack and returns back to testit (the routine that calls
newStack). I wish I could
include some graphics but I'll try to describe it with words.
I think of the stack frames as a linked list. Before newStack
returns, r1 points to the
list. newStack's frame is in the new area and testit's (the function
that called newStack) is
also in the new area. The links from stack frame to stack frame have
been set up
so that the new frame for newStack points to the new frame for
testit. The new frame
for testit points back to the original stack frame of main.
After newStack completes, the linked list of stack frames is still as
it was before except
that the top frame (testit's stack frame) is now at a different
address (in the new area).
But it points back to the original parent stack frame on the original
stack. The key here
is that testit is running on a new stack frame that newStack created
-- but, it doesn't know
If it would help, I can draw some graphics and post a link to it.
Also... I apologize for frequently sending the same message twice.
for my Apple Mail program is to send mine/html gunk. I forget to
convert it to plain text
and gcc rejects. I then have to resend it after converting it to
plain text. So, I think,
sometimes some people get two copies of the email.
Perry Smith ( email@example.com )
Ease Software, Inc. ( http://www.easesoftware.com )
Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems