Re: GCC stack size
Re: GCC stack size
- Subject: Re: GCC stack size
- From: Brian Mastenbrook <email@hidden>
- Date: Tue, 3 Mar 2009 16:00:42 -0600
On Mar 3, 2009, at 3:35 PM, Ryan McGann wrote:
We have some sample code that shows that the temporary returned from
the function doMath is allocated stack space twice, when it can only
be used once. But since the function in our actual production code
is pretty complex, it's hard to know hwich problem we are
experiencing.
However, the above examples are both well documented cases of GCC
problems; I actually got the basic ideas for both examples from
Linus Torvald's (sometimes long) emails regarding Linux's problems
with GCC stack allocation.
I've been bitten by this problem in the past as well, especially in
functions that look a lot like the examples you've given (where an
outer if wraps several complex code blocks). The worst of it is that
in this example:
void foo(int flag)
{
if (flag) {
largeStackUsingFunction();
} else {
char buf[1000];
/* ... other code which does not call functions ... */
}
}
The call to largeStackUsingFunction() will occur after the stack
pointer is adjusted for buf's usage, which can result in non-obvious
stack overflows. There is a gcc bug sitting in bugzilla to fix it, but
nothing is being done on it: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474
.
There are still a few options left to you that I can think of. The
first is to use LLVM - but in a slightly different way. Try running
the code through llvm-gcc with the C backend, and fiddling with the
different LLVM optimization settings. It's possible that llvm's better
analysis of local variable liveness will result in (mangled and
unreadable) C output that doesn't demonstrate the problem.
Another option would be to hack up a transformer using clang (assuming
your code is pure C), which would perform directed partial outlining
on the functions you've identified to be problematic.
--
Brian Mastenbrook
email@hidden
http://brian.mastenbrook.net/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden