how@IVY.UCDAVIS.EDU (W. Wilson Ho) (05/07/89)
Hi,
This is a subtle bug (or feature) of either gdb or gcc. It
only appears when you use gdb *without* using gcc:
Consider the following three files:
====
a.h
====
typedef struct a *b;
====
b.h
====
struct a {int i;};
====
test.c
====
#include "a.h"
#include "b.h"
main () {}
---------------------------------------------------------------------------
File a.h defines a type that is a pointer to a structure defined in
another file b.h.
Now compile test.c with /bin/cc, and run the program under gdb:
---------------------------------------------------------------------------
GDB 3.0, Copyright (C) 1988 Free Software Foundation, Inc.
There is ABSOLUTELY NO WARRANTY for GDB; type "info warranty" for details.
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "info copying" to see the conditions.
Reading symbol data from /usr/home/how/test/symtab/a.out...done.
Type "help" for a list of commands.
(gdb) list 1,10
1 #include "a.h"
2 #include "b.h"
3 main () {}
(gdb) ptype struct a
struct a {
int i;
}
(gdb) ptype b
struct {<no data fields>
} *
(gdb) quit
---------------------------------------------------------------------------
Gdb fails to give the correct type of b, which is a pointer to struct
a. However, dbx handles this correctly:
---------------------------------------------------------------------------
how@ivy:53> dbx a.out
Reading symbolic information...
Read 55 symbols
(dbx) whatis b
typedef struct a *b;
(dbx) whatis struct a
struct a {
int i;
};
(dbx) quit
---------------------------------------------------------------------------
Yet, if you compile the above program (test.c) with gcc, both gdb and
dbx report the type of 'b' correctly. In other words, gdb does not
understand the symbol table generated by /bin/cc, or you can also say
that gcc does not generate symbol table compatible with /bin/cc.
I've tried to trace down the source of the problem. What I found was
that the symbol tables generated by /bin/cc and gcc *are* different.
When compiled with /bin/cc, I got:
./a.h
b:t(1,2)=*(1,1)=xsa:
./b.h
a:T(2,1)=s4i:(0,1),0,32;
Type (1,1) is never defined. I suppose dbx scans through the symtab
to find the definition of struct a and links it up with the target
type of b.
When compiled with gcc:
b:t16=*17=xsa:
a:T17=s4i:1,0,32
Instead of saying the symbols 'b' and 'a' being defined in the header
files, they are all considered to be defined in the source file
(test.c), and so both debuggers have no problem processing the symtab.
Seems like to solve this problem, either gcc has to use the same
symbol table format as /bin/cc or gdb has to be fixed to handle such
symbol references across files.
Thanks for your attention!
Wilson Ho
P.S. By the way, the version of gcc I'm using is 1.26. For gdb is
3.0. All the above programs are run under BSD 4.3 in a Sun 3.
-------------------------------------------------------------------------------
W. Wilson Ho | INTERNET: how@iris.ucdavis.edu
Division of Computer Science | UUCP: ...!ucbvax!ucdavis!iris!how
EECS Department |
University of California | Phone: (916)752-7109
Davis, CA 95616 |
-------------------------------------------------------------------------------