Re: gdb 6.1 blues

[Nikos Balkanas]

Hi Eli,

Thanks for your comments. I followed them and the debug output came out
fine. One final observation:

You only need to use the optimizer when you want to debug gcc (or its
optimizer). But in that case, printfs are no better, since they change the
flow of the optimized code. For straight code debugging, no optimizer flags
should be used.

Do not worry making gdb more compatible with the -g -O2 flag. I would never
send a client a production application compiled with the -g flag, and only
on rare occasions I would use the -O2 flag.

Thanks,
Nikos
----- Original Message -----
From: "Eli Zaretskii" <address@hidden>
To: "Nikos Balkanas" <address@hidden>
Cc: <address@hidden>
Sent: Monday, March 21, 2005 7:39 AM
Subject: Re: gdb 6.1 blues


> > 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.
>