Mail Archives: djgpp/1998/08/31/04:59:48
On Sun, 30 Aug 1998, Endlisnis wrote:
> In the example I was talking about I did NOT have
> optimizations turned off. And the debugger still can't figure out
> what-is-what.
Previously, you've told that when you stepped through the code, it
seemed to be rearranged. This is normal under optimizations: the
compiler sometimes rearranges code so line number N might be executed
*after* line number N+5, especially in loops and in switch blocks.
Also, some variables are optimized out of existence: for example, a
local variable might be in a register, so it has no address, or GCC
could remove it altogether if it decides that the variable has no
effect.
However, these problems do not mean, at least in my experience, that
you cannot debug the program. They just mean that debugging is
somewhat more complicated, but still doable. A value of a missing
variable can be deduced from other variables (use the debugger feature
whereby it can compute values of expressions); rearranged code should
still make sense, since each source line should do what you wanted it
to do; etc.
Personally, I always compile all my programs with -O2 -g, even during
debugging, and debug them this way all the time. I cannot report any
show-stoppers to debugging optimized programs.
Perhaps if you could tell a bit more about your problem with debugging
optimized code, you could get some useful ideas from this forum. For
example, take one case that you couldn't debug in optimized code,
describe it here, and see what you get in reply.
> But I still have a program produces different results when
> optimizations are turned on, AND under ANY level of optimizations (including
> none) I can't debug it.
Wait a minute. You cannot debug it even under -O0? If so, then this
has nothing to do with debugging optimized code. Can you post a code
fragment that escapes debugging and explain how exactly does it
prevent you from debugging it?
- Raw text -