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.
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?
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.
Thanks for you help...
Perry Smith ( pedz@xxxxxxxxxxxxxxxx )
Ease Software, Inc. ( http://www.easesoftware.com )
Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems
