Re: alloca attribute?

[Andrew Haley <aph@redhat.com>]

Perry Smith writes:
 > On Nov 29, 2006, at 9:05 AM, Andrew Haley wrote:
 > 
 > > Perry Smith writes:
 > >> On Nov 29, 2006, at 8:24 AM, Andrew Haley wrote:
 > >>
 > >>> Perry Smith writes:
 > >> 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.
 > 
 > Ahh... I see.  It took me a while to figure out what you were saying.
 > 
 > Shoot!
 > 
 > o.k.  So if I go with the idea of newStack calling foo, will I need the
 > unwind stuff you mentioned before?  I'm somewhat terrified of
 > mucking with that but I probably need to learn how it works anyhow.

If you want to switch stacks, and you want to throw exceptions past
the switch, you'll have to create unwinder data, regardless of how you
do the stack switching.  Sorry.  If you catch all exceptions on the
other side of the stack switch so that they don't propagate past the
switch, you won't need unwinder data.

 > Is this what I need to read and understand?
 > http://www.codesourcery.com/cxx-abi/abi-eh.html
 > 
 > Or... do you have any ideas of a completely different approach somehow?

Well, I described how I thought it ought to work in a previous mail.

 > This is going to suck so bad...  all of my external entry points
 > need to move the stack.  I thought, briefly, gee, thats just the
 > five or so driver entry points.  But then there is the interrupt
 > handler, iodone, timer routines, all sorts of nasty things.

Moving the stack isn't at all unusual.  Operating systems do it all
the time.  But you've got to do it right.  Save the call-saved
registers, load fp and sp to point to the new area, and go.

Andrew.