alloca attribute?

[Perry Smith]

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