* Re: gdb 6.0
@ 2004-03-01 18:11 John David Anglin
2004-03-01 18:14 ` Daniel Jacobowitz
0 siblings, 1 reply; 7+ messages in thread
From: John David Anglin @ 2004-03-01 18:11 UTC (permalink / raw)
To: carlos; +Cc: dave.anglin, gdb
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)
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: gdb 6.0
2004-03-01 18:11 gdb 6.0 John David Anglin
@ 2004-03-01 18:14 ` Daniel Jacobowitz
2004-03-01 18:33 ` John David Anglin
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Jacobowitz @ 2004-03-01 18:14 UTC (permalink / raw)
To: John David Anglin; +Cc: carlos, dave.anglin, gdb
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gdb 6.0
2004-03-01 18:14 ` Daniel Jacobowitz
@ 2004-03-01 18:33 ` John David Anglin
2004-03-01 18:36 ` Daniel Jacobowitz
0 siblings, 1 reply; 7+ messages in thread
From: John David Anglin @ 2004-03-01 18:33 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: carlos, dave.anglin, gdb
> > (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)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gdb 6.0
2004-03-01 18:33 ` John David Anglin
@ 2004-03-01 18:36 ` Daniel Jacobowitz
2004-03-01 18:42 ` John David Anglin
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Jacobowitz @ 2004-03-01 18:36 UTC (permalink / raw)
To: John David Anglin; +Cc: carlos, dave.anglin, gdb
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gdb 6.0
2004-03-01 18:36 ` Daniel Jacobowitz
@ 2004-03-01 18:42 ` John David Anglin
2004-03-01 20:14 ` Andrew Cagney
0 siblings, 1 reply; 7+ messages in thread
From: John David Anglin @ 2004-03-01 18:42 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: carlos, dave.anglin, gdb
> 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)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gdb 6.0
2004-03-01 18:42 ` John David Anglin
@ 2004-03-01 20:14 ` Andrew Cagney
2004-03-01 20:16 ` Daniel Jacobowitz
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Cagney @ 2004-03-01 20:14 UTC (permalink / raw)
To: John David Anglin; +Cc: Daniel Jacobowitz, carlos, dave.anglin, gdb
>>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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: gdb 6.0
2004-03-01 20:14 ` Andrew Cagney
@ 2004-03-01 20:16 ` Daniel Jacobowitz
0 siblings, 0 replies; 7+ messages in thread
From: Daniel Jacobowitz @ 2004-03-01 20:16 UTC (permalink / raw)
To: Andrew Cagney; +Cc: John David Anglin, carlos, dave.anglin, gdb
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-03-01 20:16 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-01 18:11 gdb 6.0 John David Anglin
2004-03-01 18:14 ` Daniel Jacobowitz
2004-03-01 18:33 ` John David Anglin
2004-03-01 18:36 ` Daniel Jacobowitz
2004-03-01 18:42 ` John David Anglin
2004-03-01 20:14 ` Andrew Cagney
2004-03-01 20:16 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox