Re: Debug optimised code

linuxkaffee_@_gmx.net (Stephan Ceram) wrote:


> I've a question about compilers' symbolic debugging information (like
> DWARF2) and compiler optimizations. Should the code be always compiled
> without any optimizations, i.e. -O0, to get accurate debug information
> where all source code line number are correct or would I also get
> accurate results for higher optimization levels? Usually, at least
> -O1 does not modify the code too much, so I would assume that this
> optimization level could be applied for a successful debugging
> afterwards. What are you experiences?


"It depends". Different hardware architectures, languages, compilers,
and so on make a lot of difference to this.


One idea to get rid of straight away is that the names of different
optimisation levels mean very much. Higher levels of optimisation on a
given compiler mean that the intention is to produce faster code than
lower levels, which means the compile is likely to take longer and the
compiler code will probably be harder to understand and debug. Note that
all of those are intentions and probabilities; none of them are
certainties. Assuming that -O1 means that same thing on, say, GCC, a
Microsoft compiler, and an IBM compiler, will just waste your time. Each
compiler is a separate entity and needs to be dealt with on its own
terms.


For many things, deoptimising is the best bet. However, there are cases
when the behaviour of optimised and deoptimised code differs, apart from
performance. These include compiler bugs, code bugs that only show up
when the compiler arranges variables in a stack frame in a specific way,
and other things.


So the general start point is to deoptimise, but if your problem goes
away when you do that, you have to start debugging optimised code. This
is always harder; depending on the architecture and the degree of
optimisation you need to turn on to get the problem to show, it may be a
lot harder.


One thing you have to get used to for debugging even lightly optimised
code, is that some variables will spend some or all of their lives in
registers. Since many debuggers consider that variables live in memory
locations, such debuggers won't display the values of variables that are
currently in registers correctly. Sometimes you can work around this
with print statements or other debugging code. That may seem crude, and
it is slow, but it often works. However, sometimes putting in printing
changes the code enough to make the problem go away. That's a clue in
itself.


There's another way round the problem of variables in registers, but it
takes work: you need to learn to read the machine's assembly language
somewhat, and then relate the debugger's disassembly listing and/or the
compiler's assembly listing of the code to your execution position in
the debugger. Then you know which register contains the variable you're
interested in.


It's a learning experience. The learning curve is fairly steep, but once
you've learned it for one platform, learning it for others is a lot
easier.


There's also a potential reverse problem: there have been compilers
where turning on full debugging information, without lowering
optimisation, changes the generated code. Sometimes, this makes problem
go away. Fortunately, it's rare these days. Getting partial debug
information from the compiler is better than getting full information
and changed code.


--
John Dallman, jgd@cix.co.uk, HTML mail is treated as probable spam.

Return to the comp.compilers page.
Search the comp.compilers archives again.