"Daniel Berlin" <[EMAIL PROTECTED]> writes: > You are about 3 years late to the party on this one :) > > http://gcc.gnu.org/ml/gcc/2005-03/msg00568.html
Yup. > Realistically, you are not going to be able to get good stacktraces > with optimized code for *other* reasons, abort is just the first thing > you hit. Oh, we are not talking about "not good stacktraces" here. We are talking about "completely different location, possibly even in a different function, and debug info that has nothing to do with the actual state of the stack frame". "Not good" is expected with optimization. "Catastrophically misleading" is a different category. Since one of the main points of "abort" _is_ the stack trace, that's a particularly bad function call to optimize in this manner. Omitting either the -fcrossjumping _or_ the noreturn optimizations would get this back into the "expected consequence of optimization on debugging" scale. It is the combination of them that makes it impossible for the debugger to figure out the current call situation and temporary variable/register/stackframe assignments. > You are much better off making an abort that gives you more correct > info (see, for example gcc's fancy_abort) than trying to take the info > you get at some random point in an optimized program, and then trying > to build it into something useful for the user (as abort does). But fancy_abort does not help in examining variables: they may be sitting on the stack or in registers. Without noreturn optimizations, at least the compiler would only crossjump to abort calls with equal continuation and equal data locations, so examining variables is still possible in the debugger and one can get a good guess at where one is currently. And without crossjumping, the debugging info might tell the debugger just how garbled the current data locations are. But with both active, stack data and return addresses are garbage. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
