site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Mar 3, 2009, at 3:35 PM, Ryan McGann wrote: void foo(int flag) { if (flag) { largeStackUsingFunction(); } else { char buf[1000]; /* ... other code which does not call functions ... */ } } 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: 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 brian@mastenbrook.net http://brian.mastenbrook.net/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com
participants (1)
-
Brian Mastenbrook