This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
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.

O.k.



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.

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, obviously, is
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
that.


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. The default
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 ( pedz@easesoftware.com )
Ease Software, Inc. ( http://www.easesoftware.com )

Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]