Gcc options for improving debugging?

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/~a
lex/
Hardware, n.: The parts of a computer system that can be
kicked.

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

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/~a
lex/
The new Congressmen say they're going to turn the
government around. I
hope I don't get run over again.

Alex Bennee <kernel-hackerbennee.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

Alex Bennee <kernel-hackerbennee.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

Alex Bennee <kernel-hackerbennee.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

Alex Bennee <kernel-hackerbennee.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

Alex Bennee <kernel-hackerbennee.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