Re: Debug optimized code

On Sep 17, 6:28 pm, Walter Banks <wal...@bytecraft.com> wrote:
> 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


It depends on the implementation of the compiler. Compilers emit dwarf
information (latest on dwarf is DWARF3) that takes into account how
they messed up the structure of the input source code. As optimization
levels increase, the change that is made to underlying source code
increases and the compiler has difficulty in traching the change that
was made and so you will get mis-leading info when the debugger reads
in the dwarf info and points to something else as the cause of the
problem.


> > 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?
>
yes -debug the application before optimizing.


> Stephan,
>
> This is an incredibly important topic.
>
> Earlier in the week I was talking to a developer about optimization
> and it became clear that the reason he wanted optimization off in the
> tools he was using was in the tools he was familiar with was so the
> source level debugging information reflected the application. In an
> example he showed me with higher levels of optimization the compiler
> temporarily used a register as a variable but the debugging
> information showed the variable as located in the RAM address it was
> assigned to.
>
> The developer explained that he debugged the application with their
> tools with optimization off and re-compiled and shipped.
>
> This is scary for two reasons, there is an assumption that the
> compiled code and application timing will function the same
that is always a risk even with varying system loads.


> independent of optimization level. Secondly, code was being shipped
> without rigorous testing.
>
you can test optimized code if you like.


> The problem is in the compiler not the source level debugging format.
> In the example above there is is no problem describing that a variable
> is in a specific register for a specific execution range.
>
> The compiler technology to do this has been available for 15 years or
> so. In the last few days this is the third reference to the problem I
> have seen.
>
> A short survey here might help point to what compilers (open source or
> commercial) generate source level debugging information that tracks
> the optimizations used to generated code.


HP's C compiler can provide almost accurate information upto +O2. At
+O2, problems start to show up in some cases. {i don't represent the
concerned developers who put in the DOC/test it -but this is common
knowledge]. Some companies ship out unoptimized code when it is
unstable, and once they are convinced -optimize it.


  I am not sure when you will hit a case that program ehaviour got
altered by a valid optimization strategy -unless you are debugging the
compler/filing a bug against the compiler vendor instead of the
application writer.


thanks
-kamal

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