This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Major improvement to the Xconq kernel
> (I think I heard somewhere, perhaps on the gcc list, that -O and -g
> should now be able to work together without significant problems.) My
> experience has been that if the two are used together, then sometimes
> you need to step a few lines before GDB will "backtrack" to the
> variable in question and show its assigned value; I assume that this
> is simply because the optimizer reorders instructions and it is harder
> to know when to associate a line with an instruction.
The kind of thing which you describe has always been typical of what
happens with -O and -g. I call it a "significant problem" trying to
debug code this way, though that is partly a matter of opinion.
Stepping is not an option; I only had a core dump, not a running copy.
In general, you need to read the disassembly to figure out what is
going on, and who wants to bother?
> I can filter -O out of the default CFLAGS for the GNU compilers,
> if there is a consensus that this should be done. I know that
> Peter is leary about debugging optimized code.
I suspect the default is chosen with production, rather than
debugging, in mind. Even for production, this might be misguided:
even a user which knows nothing about debugging could send in a
backtrace after a core dump. Although there's also a case for the
status quo (don't know if anyone has tried to measure the performance
gain from -O).
Meanwhile, I can always change my own CFLAGS.