gdb 6.1 blues
Hi,
I am using gdb 6.1.1 on a SuSE professional 9.1 box.
gcc is 3.3.3
Kernel is 2.6.4-52 custom.
Problem:
(1) Source lines get messed up
(2) Just evaluated variables, are "out of context" (may
be previous problem)
These 2 problems render gdb unusuable and I have to resort on
printfs for debugging.
Conditions:
Files nbssh.c, libssh.a
libssh.a: ${OBJECTS}
ar rv libssh.a ${OBJECTS}
auth.o: auth.c
gcc
-g -O2 -Wall -I../include/ -c -o auth.o auth.c
nbssh: nbssh.c libssh.a
gcc
-Wall -g -I. -c nbssh.c
gcc
nbssh.o libssh.a -lcrypto -lz -o nbssh
Test run (line numbers omitted):
$ 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)
> p err
>> variable "err" not available
Source of auth.c at this point is:
int ssh_userautrh_kbdint(SESSION *session, char *username,
char *password){
SESSION *session1;
int err = 0;
if (!username)
{
Observations:
Gdb seems to enter the same function twice, without the source
code saying so. Also, variable err is initialized and within context, when it
reaches the username conditional. Gdb should know about it.
Also I remember sometime ago that in the todo list was on fork
to be able to follow either the child or the parent. Has this been
implemented?
Thanks,
Nikos Balkanas
___
Bug-gdb mailing list
Bug-gdb@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: gdb 6.1 blues
> From: "Nikos Balkanas" <[EMAIL PROTECTED]> > 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. ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: gdb 6.1 blues
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" <[EMAIL PROTECTED]> To: "Nikos Balkanas" <[EMAIL PROTECTED]> Cc: Sent: Monday, March 21, 2005 7:39 AM Subject: Re: gdb 6.1 blues > > From: "Nikos Balkanas" <[EMAIL PROTECTED]> > > 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. > ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
