Re: alloca attribute?

[Andrew Haley <aph at redhat dot com>]

Perry Smith writes:
 > I wrote a class that switches the stack to a new area.  This is for  
 > the power PC.
 > 
 > In the text below, I'll use main, testit, and newStack.  main is the  
 > main program, testit is a function that main calls, and newStack is  
 > the method that switches the stack to the new space.  main calls  
 > testit which calls s.newStack.  (s is an instance of the class that  
 > switches the stack).
 > 
 > The purpose of separating main and testit is so I can verify that  
 > returning from testit works properly.
 > 
 > newStack gets the current value of r1 (the stack pointer) and copies  
 > the last two stack frames (which would be the stack frame for testit  
 > and newStack) to the top of some allocated memory.  It alters r1(0)  
 > (the previous stack value for newStack) in the new memory to point to  
 > the address of testit's new stack frame.  It sets r1 up to the base  
 > of this new area and returns.

OK, before we go any further.  Did you write and test DWARF unwinder
information for newStack?

 > With g++ and no optimization, this works.  When newStack returns,
 > it consumes its stack frame in the new memory leaving only testit's
 > new stack frame and r1 pointing to the base of the new stack from
 > for testit.  When testit returns, it loads r1 with r1(0) and
 > returns.  This properly puts r1 back to main's stack frame.
 > 
 > If I put -O3, then at the return of testit, instead of loading r1
 > with r1(0), just adds in the size of the stack frame (and assumes
 > that r1 has not been munged with).  I presume this is faster.  I
 > know that xlc does the same thing.  As a result, when we return
 > back to main, the stack pointer is off in the weeds somewhere.

I get the feeling I'm not understanding something here.  As long as
newStack is correct and handles all registers according to the ABI,
there shouldn't be any trouble.

Andrew.