Re: gdb 6.0

Re: gdb 6.0

[John David Anglin]

High c.,

Have you started work on gdb?  This weekend I was working on a patch
for the GCC testsuite to make it correctly honor a preexisting
LD_LIBRARY_PATH.  This exposed a couple of problems related to
dwarf2 exception support (e.g., g++.dg/eh/forced1.C).  This test
passes with sjlj exceptions but fails with dwarf2 exceptions.  I
started trying to debug this but found gdb dumps core trying to
read the symbol table of libgcc_s.so.2 :(

(gdb) sharedlibr /home/dave/gcc-3.5/objdir/gcc/libgcc_s.so.2
Reading symbols from /home/dave/gcc-3.5/objdir/gcc/libgcc_s.so.2...done.
Loaded symbols for /home/dave/gcc-3.5/objdir/gcc/libgcc_s.so.2
Segmentation fault (core dumped)

The details are:

#0  decode_locdesc (blk=0x55cd, objfile=0x38b598, cu_header=0x0)
    at ../../gdb-6.0/gdb/dwarf2read.c:6771
#1  0x0012f2d0 in new_symbol (die=0x37e248, type=0x0, objfile=0x31ac08,
    cu_header=0xfaf01d08) at ../../gdb-6.0/gdb/dwarf2read.c:5210
#2  0x0012a08c in process_die (die=0x37e248, objfile=0x31ac08,
    cu_header=0xfaf01d08) at ../../gdb-6.0/gdb/dwarf2read.c:1835
#3  0x0012a7c0 in read_func_scope (die=0x37e1b0, objfile=0x31ac08,
    cu_header=0xfaf01d08) at ../../gdb-6.0/gdb/dwarf2read.c:2088
#4  0x0012a424 in read_file_scope (die=0x379ae0, objfile=0x31ac08,
    cu_header=0xfaf01d08) at ../../gdb-6.0/gdb/dwarf2read.c:1948
#5  0x00129be4 in psymtab_to_symtab_1 (pst=0x3694b0)
    at ../../gdb-6.0/gdb/dwarf2read.c:1702
#6  0x0012999c in dwarf2_psymtab_to_symtab (pst=0x3694b0)
    at ../../gdb-6.0/gdb/dwarf2read.c:1616
#7  0x0007b790 in psymtab_to_symtab (pst=0x3694b0)
    at ../../gdb-6.0/gdb/symfile.c:304
#8  0x00077f4c in find_pc_sect_symtab (pc=1075639268, section=0x0)
    at ../../gdb-6.0/gdb/symtab.c:1844
...

(gdb) p blk
$1 = (struct dwarf_block *) 0x55cd
(gdb) printf "0x%x\n",$pcoqh
0x131c73
(gdb) disass 0x131c60 0x131c80
Dump of assembler code from 0x131c60 to 0x131c80:
0x00131c60 <decode_locdesc+56>: stw r6,-40(,sp)
0x00131c64 <decode_locdesc+60>: stw r5,-3c(,sp)
0x00131c68 <decode_locdesc+64>: stw r4,-38(,sp)
0x00131c6c <decode_locdesc+68>: stw r3,-34(,sp)
0x00131c70 <decode_locdesc+72>: ldw 0(,r26),r7
0x00131c74 <decode_locdesc+76>: copy r25,r8
0x00131c78 <decode_locdesc+80>: addil 21000,dp,%r1
0x00131c7c <decode_locdesc+84>: copy r1,r12
End of assembler dump.
(gdb) ptype blk
type = struct dwarf_block {
    unsigned int size;
    char *data;
} *
(gdb) info addr blk
Symbol "blk" is an argument in register r26.

(gdb) p *die
$4 = {tag = DW_TAG_formal_parameter, has_children = 0, abbrev = 31,
  offset = 63577, num_attrs = 5, attrs = 0x37e270, next_ref = 0x0,
  next = 0x37e2b0, type = 0x0}
(gdb) p die->attrs[0]
$5 = {name = DW_AT_name, form = DW_FORM_strp, u = {str = 0x34a278
"encoding",
  blk = 0x34a278, unsnd = 3449464, snd = 3449464, addr = 3449464}}
(gdb) p die->attrs[1]
$6 = {name = DW_AT_decl_file, form = DW_FORM_data1, u = {
  str = 0x1 <Address 0x1 out of bounds>, blk = 0x1, unsnd = 1, snd = 1,
  addr = 1}}
(gdb) p die->attrs[2]
$7 = {name = DW_AT_decl_line, form = DW_FORM_data1, u = {
  str = 0x4a <Address 0x4a out of bounds>, blk = 0x4a, unsnd = 74, snd = 74,
  addr = 74}}
(gdb) p die->attrs[3]
$8 = {name = DW_AT_type, form = DW_FORM_ref4, u = {
  str = 0x45 <Address 0x45 out of bounds>, blk = 0x45, unsnd = 69, snd = 69,
  addr = 69}}
(gdb) p die->attrs[4]
$9 = {name = DW_AT_location, form = DW_FORM_data4, u = {
  str = 0x55cd <Address 0x55cd out of bounds>, blk = 0x55cd, unsnd = 21965,
  snd = 21965, addr = 21965}}

The misaligned address for "blk" comes from the above.  I know next to
nothing about the dwarf2 encoding but I would guess that the symbol table
is wrong, although it might be a problem in dwarf2read.c.  This was with
gdb-6.0-2.

Thoughts?

I think I will build GCC with -gstabs so I can debug the forced1.C
problem.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX:
952-6602)

Re: gdb 6.0

[Daniel Jacobowitz]

On Mon, Mar 01, 2004 at 01:03:00PM -0500, John David Anglin wrote:
> High c.,
> 
> Have you started work on gdb?  This weekend I was working on a patch
> for the GCC testsuite to make it correctly honor a preexisting
> LD_LIBRARY_PATH.  This exposed a couple of problems related to
> dwarf2 exception support (e.g., g++.dg/eh/forced1.C).  This test
> passes with sjlj exceptions but fails with dwarf2 exceptions.  I
> started trying to debug this but found gdb dumps core trying to
> read the symbol table of libgcc_s.so.2 :(
> 
> (gdb) sharedlibr /home/dave/gcc-3.5/objdir/gcc/libgcc_s.so.2
> Reading symbols from /home/dave/gcc-3.5/objdir/gcc/libgcc_s.so.2...done.
> Loaded symbols for /home/dave/gcc-3.5/objdir/gcc/libgcc_s.so.2
> Segmentation fault (core dumped)

GDB 6.0 can't be used with GCC 3.4/3.5, for this exact reason.  I think
it's caused by var-tracking; you might be able to turn that off
separately.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb 6.0

[John David Anglin]

> > (gdb) sharedlibr /home/dave/gcc-3.5/objdir/gcc/libgcc_s.so.2
> > Reading symbols from /home/dave/gcc-3.5/objdir/gcc/libgcc_s.so.2...done.
> > Loaded symbols for /home/dave/gcc-3.5/objdir/gcc/libgcc_s.so.2
> > Segmentation fault (core dumped)
> 
> GDB 6.0 can't be used with GCC 3.4/3.5, for this exact reason.  I think
> it's caused by var-tracking; you might be able to turn that off
> separately.

Is this fixed in the current CVS source?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: gdb 6.0

[Daniel Jacobowitz]

On Mon, Mar 01, 2004 at 01:33:36PM -0500, John David Anglin wrote:
> > > (gdb) sharedlibr /home/dave/gcc-3.5/objdir/gcc/libgcc_s.so.2
> > > Reading symbols from /home/dave/gcc-3.5/objdir/gcc/libgcc_s.so.2...done.
> > > Loaded symbols for /home/dave/gcc-3.5/objdir/gcc/libgcc_s.so.2
> > > Segmentation fault (core dumped)
> > 
> > GDB 6.0 can't be used with GCC 3.4/3.5, for this exact reason.  I think
> > it's caused by var-tracking; you might be able to turn that off
> > separately.
> 
> Is this fixed in the current CVS source?

Yes, and HP/UX support in the current CVS source is pretty good; but
the PA Linux patches will not apply without some serious work.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb 6.0

[John David Anglin]

> Yes, and HP/UX support in the current CVS source is pretty good; but
> the PA Linux patches will not apply without some serious work.

I have some cleanups for HP/UX which I can now submit as my gdb
paperwork is now complete.  I did a build last night and a few new
warnings have appeared since early Jan.

Carlos had offered to work on getting the debian PA Linux patches
integrated.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: gdb 6.0

[Andrew Cagney]

>>Yes, and HP/UX support in the current CVS source is pretty good;

I wouldn't go that far (I can get away with saying that 'cos its been me 
hacking on it :-).  The 32-bit PA support is, lets say, "functional".

 >> but
 >> the PA Linux patches will not apply without some serious work.

> I have some cleanups for HP/UX which I can now submit as my gdb
> paperwork is now complete.  I did a build last night and a few new
> warnings have appeared since early Jan.
> 
> Carlos had offered to work on getting the debian PA Linux patches
> integrated.

Can I suggest worrying about -nat changes?  As Daniel hints, anything to 
hppa-tdep.c is probably no longer applicable (or needs serious thought).

Andrew

Re: gdb 6.0

[Daniel Jacobowitz]

On Mon, Mar 01, 2004 at 03:13:54PM -0500, Andrew Cagney wrote:
> >>Yes, and HP/UX support in the current CVS source is pretty good;
> 
> I wouldn't go that far (I can get away with saying that 'cos its been me 
> hacking on it :-).  The 32-bit PA support is, lets say, "functional".
> 
> >> but
> >> the PA Linux patches will not apply without some serious work.
> 
> >I have some cleanups for HP/UX which I can now submit as my gdb
> >paperwork is now complete.  I did a build last night and a few new
> >warnings have appeared since early Jan.
> >
> >Carlos had offered to work on getting the debian PA Linux patches
> >integrated.
> 
> Can I suggest worrying about -nat changes?  As Daniel hints, anything to 
> hppa-tdep.c is probably no longer applicable (or needs serious thought).

These patches didn't use hppa-tdep.c at all - they created a parallel
pa-tdep.c without HP/UX support.  Beyond that I have absolutely zero
idea what the differences are.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer