🚀 go-pugleaf

In article <9207292148.AA07756@is22.isoft.fr> slt@is22.ISoft.FR (Stephane Tsacas) writes:
>Hello,
>
>I'm using gdb 4.5 compiled for a sparc (sunos 4.1.1).
>
>With the following program :
>
>#include <sys/types.h>
>#include <sys/time.h>
>#include <sys/proc.h>
>
>
>struct proc p;
>
>struct _struct1
>{
>  struct _struct1 *pstruct1;
>  int rest;
>};
>
>struct _struct1 struct1;
>
>main() {; }
>
>(gdb) ptype struct _struct1
>type = struct _struct1 {
>    struct _struct1 *pstruct1;
>    int rest;
>}
>
>;;; OK
>
>But now, if I do `ptype struct proc', each component of struct proc
>which is a `struct proc *' is expanded :
>
>(gdb) ptype struct proc
>type = struct proc {
>    struct {
>        struct <unknown> p_link;
>        struct <unknown> p_rlink;
>        struct <unknown> p_nxt;
>        struct <unknown> *p_prev;
>        struct as *p_as;
>        struct seguser *p_segu;
....

>... for each struct proc * ...
>
>I don't understand why the output differs.
>

I played around with this a bit.  First I tried it on our gdb
(4.3 based , reads dwarf), and it was OK.  Then I tried it on
a sparc with gdb.  Anyway, the problem seems to be in the compiler.

Compile the program with gcc, and the ptype info from gdb is OK.
Compile with cc and the ptype info is ng.

I looked at <sys/proc.h>.  It includes <sys/user.h> which in
turn includes <sys/proc.h>.  I think that somehow this is confusing
cc, since I tried a small test program (two, actually):

#include <sys/user.h>
main()
{
;
}
For this one, ptype struct proc is ok (even from cc).

But for this one:

#include <sys/proc.h>
main()
{
;
}

it isn't.  I looked at the stabs, and sure enough, it's OK for the first
case, but for the second it's not (it references something that's never
defined, just like gdb says.)

>Also, `info variables' expand p but not struct1, why ?
>
>
>When I type `gdb bar.o' then `info variables' gdb crashes if bar.o
>does not countain a main() fonction.  If this can help :
>(top-gdb) r /tmp/bar.o
>Starting program: /mnt/GNU/gdb-4.5/gdb/gdb /tmp/bar.o
>GDB is free software and you are welcome to distribute copies of it
> under certain conditions; type "show copying" to see the conditions.
>There is absolutely no warranty for GDB; type "show warranty" for details.
>GDB 4.5, Copyright 1992 Free Software Foundation, Inc...
>Setting up the environment for debugging gdb.
>
>Program received signal 11, Segmentation fault
>During symbol reading, bad block start address patched.
>0x28000 in lookup_symbol (name=0xf7fff928 "fatal", block=0x0, 
>    namespace=VAR_NAMESPACE, is_a_field_of_this=0x0, symtab=0xf7fff954)
>    at symtab.c:472
>472               ALL_MSYMBOLS (objfile, msymbol)
>(top-gdb)  p objfile->msymbols
>$3 = (struct minimal_symbol *) 0x0
>(top-gdb) 
>
gdb is supposed to run on executables, not on ".o" files!

But if you try to run it on a ".o", it does indeed crash like this.

I don't know if it's possible to tell sun ".o"'s from linked executables,
but it sounds like a worthwhile check to put in.
>
>  ,
>Stephane
>
>
>Stephane Tsacas			UUCP: slt@isoft.fr
>1/3 av. Brancion, bat B		slt%isoftfr@uunet.UU.NET
>75015 Paris			Phone: (33-1) 48 28 4994 / (33-1) 64 46 1748
>France				<<PUSHJ P, POPJ P, recursively>>


Hope this helps.

Peggy