murf@CS.UTEXAS.EDU (Steve Murphy) (04/19/89)
gdb prints out the definition backwards with "whatis". To be explicit:
If the program says:
struct commands
{
int numof;
char line[30][17][25];
}
An excerpt from gdb 3.1.2 (but I believe this has always been this
way- I think):
(gdb) whatis commands
type = struct commands {
int numof;
char line[25][17][30];
}
===========================================================================
A like problem:
on source compiled with sun's 3.5 cc, this declaration:
check_measure_line(inline)
char inline[17][25];
{
will be handled by gdb as such:
(gdb) p inline
$2 = (char *[100]) 0x5823c
don't feel bad, because dbx agrees a little:
(dbx) whatis inline
char (*inline)[100];
which seems a bit far-fetched to me.
I compile with gcc1.34 and get this:
Bpt 1, check_measure_line (inline=(char *[25]) 0x59c20) (Z.c line 1178)
and dbx says:
(dbx) whatis inline
char (*inline)[25];
What am I saying? Well, it appears from the above that sun's cc set
isn't recording the right sym stuff for arrays. Gcc appears to, but
still gdb seems to confuse pointers to arrays with arrays of pointers
in its notation when describing types.
=========================================================================
Another bee in my bonnet:
Stack trace printout on stuff not compiled with the -g flag:
While dbx gives you this kind of thing:
stopped in check_measure_line at 0x6910
check_measure_line+4: movl d2,sp@-
(dbx) where
check_measure_line(0x59c20) at 0x6910
check_measure_file() at 0x6d3f
main(0x4, 0xefff70c, 0xefff720) at 0xa26b
(dbx)
Gdb will only give you this:
Bpt 1, 0x5e80 in check_measure_line ()
(gdb) where
#0 0x5e80 in check_measure_line ()
#1 0x6326 in check_measure_file ()
#2 0x9964 in main ()
(gdb)
I may be old fashioned, but if the info is there, why not print it,
even if is just a bunch of hex numbers? A quick look at the contents
of what looks like a pointed to address might reveal much knowlege
about a possible crash....
murf