gdb 6.1 blues

[Nikos Balkanas]

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: 
functionssh_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

[Eli Zaretskii]

 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