Re: gdb 6.1 blues

[Eli Zaretskii]

> From: "Nikos Balkanas" <address@hidden>
> Date: Mon, 21 Mar 2005 04:42:19 +0200
> 
> Problem:
> 
> (1) Source lines get messed up
> (2) Just evaluated variables, are "out of context" (may be previous
> problem)

These all happen because of the compiler optimizations (the -O2 switch
to GCC):

> auth.o:  auth.c
>             gcc -g -O2 -Wall -I../include/ -c -o auth.o auth.c

The optimizer rearranges code so that a single source line may be
split between several different code locations, that's why stepping in
GDB appears to execute a line several times.

Btw, it's better to use -ggdb3 instead of -g, as that might give GDB
better debug info and help it help you during debugging.

> These 2 problems render gdb unusuable and I have to resort on printfs
> for debugging.

If you did this because you don't believe the debugger is showing you
the truth, then believe it, and use one of the 2 techniques below.

First, you can always compile without optimizations.  But that has a
disadvantage that you will be debugging a very different program than
you will later use in production, so I recommend this only as the last
resort.

To debug an optimized program, you need to step through the code until
the source line you are interested in is no longer shown.  For
example, in this case:

> $ gdb nbssh
> > b ssh_userauth_kbdint
> > r 127.0.0.1
> >> Breakpoint 1 file auth.c: function  ssh_userauth_kbdint ...
> >>         int err = 0;
> > n
> >> int ssh_userautrh_kbdint(SESSION *session ...)
> > n
> >> if (!username)

type "n" a few more times, and you will see that the same few first
lines of the function are shown time and again.  Wait until you get to
the line after "if (!username)", and then you can be sure that the
code produced by the first few lines of the function was executed in
its entirety, and the `err' variable's value can then be printed.

As for this:

> > p err
> >> variable "err" not available

the optimizer could sometimes optimize a variable out of existence, or
put it into a register.  So get used to the commands "info address"
and "info locals" to find out which local variables are stored where.
Here, too, while you are still in the function's prologue, GDB might
say that a variable is not in the current context, so step a while
into the function and try again.

Debugging an optimized program like this takes used to, but it is
certainly doable, and the advantage is that you are debugging teh same
code you (or your clients) will be using in production.