Gcc options for improving debugging?

Gcc options for improving debugging?

[Alex Bennee]

Hi,

By default we build our software with -O3 which brings in a host of
optimisations which make following code in GDB a pain. Artifacts I have
to deal with include:

* this=Variable "this" is not available and friends
* funky execution order when tracing
* Compressed backtraces due to inlineing

Now I have tackled this one way by introducing a -O0 variant of our
build for debugging. However it's becoming more tricky to compile with
low optimisation levels when we have some quite complex inline assembler
that needs a certain level of optimisation to be able to derive
constants from C++ functions.

An alternate approach is to compile with -O3 but turn off specific
optimisations which make life tricky for gdb. So far I have:

* -ggdb3  (obviously)
* -fno-omit-frame-pointer (seems to help with finding some variables)

What else would you suggest? Would this be worth adding to section 4.1
of the manual "Compiling for debugging".

--
Alex, homepage: http://www.bennee.com/~alex/
Hardware, n.: The parts of a computer system that can be kicked.

Re: Gcc options for improving debugging?

[Daniel Jacobowitz]

On Wed, Jul 19, 2006 at 12:32:58PM +0100, Alex Bennee wrote:
> An alternate approach is to compile with -O3 but turn off specific
> optimisations which make life tricky for gdb. So far I have:
> 
> * -ggdb3  (obviously)

This doesn't really give you anything beyond -g.  The only difference
is that it will allow you to expand macros, and make your object files
huge.

> * -fno-omit-frame-pointer (seems to help with finding some variables)
> 
> What else would you suggest? Would this be worth adding to section 4.1
> of the manual "Compiling for debugging".

Beyond this there's not really much you can do.  If you need inlining,
you're in trouble, because GDB does not (yet) have decent inlining
support - but it's on the list of things to improve.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Gcc options for improving debugging?

[Alex Bennee]

On Wed, 2006-07-19 at 09:05 -0400, Daniel Jacobowitz wrote:
> On Wed, Jul 19, 2006 at 12:32:58PM +0100, Alex Bennee wrote:
> > An alternate approach is to compile with -O3 but turn off specific
> > optimisations which make life tricky for gdb. So far I have:
> > 
> > * -ggdb3  (obviously)
> 
> This doesn't really give you anything beyond -g.  The only difference
> is that it will allow you to expand macros, and make your object files
> huge.

I was wondering what the difference was between that and -g3. Thanks.

> 
> > * -fno-omit-frame-pointer (seems to help with finding some variables)
> > 
> > What else would you suggest? Would this be worth adding to section 4.1
> > of the manual "Compiling for debugging".
> 
> Beyond this there's not really much you can do.  If you need inlining,
> you're in trouble, because GDB does not (yet) have decent inlining
> support - but it's on the list of things to improve.

Is it the inlineing that's causing the variables to get optimised
away??? That's my biggest problem at the moment.

--
Alex, homepage: http://www.bennee.com/~alex/
The new Congressmen say they're going to turn the government around. I
hope I don't get run over again.

Re: Gcc options for improving debugging?

[Paul Koning]

>>>>> "Alex" == Alex Bennee <kernel-hacker@bennee.com> writes:

 Alex> Is it the inlineing that's causing the variables to get
 Alex> optimised away??? 

No.  GCC can make variables go away without any inlining.  And even if
a variable isn't optimized away completely, it can become "dead" at
some point (when it is not needed in the rest of the function).  When
that happens, the register gets reused but GDB doesn't necessarily
know that.  So you can still see the variable but the values it
appears to have are wrong because that register now contains something
else.

	paul

Re: Gcc options for improving debugging?

[Daniel Jacobowitz]

On Wed, Jul 19, 2006 at 01:49:54PM -0400, Paul Koning wrote:
> >>>>> "Alex" == Alex Bennee <kernel-hacker@bennee.com> writes:
> 
>  Alex> Is it the inlineing that's causing the variables to get
>  Alex> optimised away??? 
> 
> No.  GCC can make variables go away without any inlining.  And even if
> a variable isn't optimized away completely, it can become "dead" at
> some point (when it is not needed in the rest of the function).  When
> that happens, the register gets reused but GDB doesn't necessarily
> know that.  So you can still see the variable but the values it
> appears to have are wrong because that register now contains something
> else.

In addition to what Paul said:  Alex, you may want to try upgrading to
GDB 6.5.  Previous versions had a much more annoying behavior when this
happened, but 6.5 is better about it; from your initial report I guess
you're using something earlier.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Gcc options for improving debugging?

[Paul Koning]

>>>>> "Alex" == Alex Bennee <kernel-hacker@bennee.com> writes:

 Alex> Hi, By default we build our software with -O3 which brings in a
 Alex> host of optimisations which make following code in GDB a
 Alex> pain.

Sure enough, exactly as documented.

 Alex> An alternate approach is to compile with -O3 but turn off
 Alex> specific optimisations which make life tricky for gdb. So far I
 Alex> have:

 Alex> * -ggdb3 (obviously) * -fno-omit-frame-pointer (seems to help
 Alex> with finding some variables)

-ggdb3???  That's not an optimization option.

I find that the simplest and best answer is to do most debugging using
a version compiled with -O1.  That gives you inline assembler,
inlining of things that are specifically called out to be inlined,
etc.  But it doesn't do much instruction reordering.

      paul

Re: Gcc options for improving debugging?

[Frank Ch. Eigler]

Alex Bennee <kernel-hacker@bennee.com> writes:

> By default we build our software with -O3 which brings in a host of
> optimisations which make following code in GDB a pain. [...]
> An alternate approach is to compile with -O3 but turn off specific
> optimisations which make life tricky for gdb. [...]

There is an increasing appreciation in gcc land for the need to debug
fully optimized programs, which is manifesting itself with gradual
improvements in the quality of debugging information gcc emits.  For
those cases where the data is outright missing or incorrect, you will
get more sympathy for such bug reports than perhaps in the past.

None of that may actually unravel inherent phenomena such as "funky
execution order" or "compressed backtraces", but they should improve
accurate visibility of those source-level constructs that survive into
the binary stage.

- FChE