Re: alloca attribute?

[Andrew Haley <aph at redhat dot com>]

Perry Smith writes:
 > 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). 

You're right.  It sucks.  :-)

 > I wish I could include some graphics but I'll try to describe it
 > with words.

No, you've explained it perfectly well, but trust me here: it's a
really bad idea.  gcc can eliminate the stack pointer to the frame
pointer, as you have discovered.  gcc can also save a pointer to a
local area on the stack, and that can be of indeterminate size.

So gcc might do this

   int a = 2;
   p = &a;  // allocated on the stack
   newStack();
   *p = 3;
   print a;

And a, being on the new stack, would now be different from *p, which
still points to the old stack.  It can't possibly work.

Andrew.