This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]