This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb/1179: GNU/Linux, SUN/Solaris, Diab C++ compiler 4.3, Target PowerPC


The following reply was made to PR gdb/1179; it has been noted by GNATS.

From: Daniel Jacobowitz <drow at mvista dot com>
To: gerhard dot jacobs at marconi dot com
Cc: gdb-gnats at sources dot redhat dot com
Subject: Re: gdb/1179: GNU/Linux, SUN/Solaris, Diab C++ compiler 4.3, Target PowerPC
Date: Tue, 15 Apr 2003 08:58:40 -0400

 Can Diab generate DWARF-2 information?  There are a huge number of
 known problems with GDB's DWARF-1 support, and it looks like that is
 what you are using.
 
 
 On Tue, Apr 15, 2003 at 08:50:06AM -0000, gerhard dot jacobs at marconi dot com wrote:
 > 
 > >Number:         1179
 > >Category:       gdb
 > >Synopsis:       GNU/Linux, SUN/Solaris, Diab C++ compiler 4.3, Target PowerPC
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    unassigned
 > >State:          open
 > >Class:          change-request
 > >Submitter-Id:   net
 > >Arrival-Date:   Tue Apr 15 08:58:00 UTC 2003
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Gerhard Jacobs
 > >Release:        GNU gdb 5.3
 > >Organization:
 > >Environment:
 > Linux 2.4.18.4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686
 > gcc version 3.0.4 (SuSE)
 > GNU gdb 5.3
 > This GDB was configured as "--host=i686-pc-linux-gnu"
 >  --target="powerpc-860-elf".
 > dcc Rel 4.3 Rev g
 > Table: PowerPC  Rel. 4.3g
 > >Description:
 > We use GDB to cross-debug programs for a PPC target
 > (with a BDI2000 BDM box as remote target)
 > 
 > The software is compiled and linked into an ELF-file
 > with Diab's C++ compiler
 > 
 > We can run and step and set breakpoints in the target
 > alright, and we can load the symbols from the ELF-file.
 > 
 > But as soon as GDB wants to display a C++ source text,
 > it crashes with a Segmentation Fault, dumping the core.
 > 
 > 
 > Debugging the core dump got me the following backtrace
 > (I left out the first few lines)
 > 
 > backtrace:
 > 
 > ...
 > execute_command() top.c#711
 > cmd_func() cli-decode.c#1532
 > do_cfunc() cli-decode.c#53
 > line_info() source.c#1329
 > decode_line_spec_1() breakpoint.c#7481
 > decode_line_1() linespec.c#945
 > lookup_symtab() symtab.c#216
 > psymtab_to_symtab() symfile.c#375
 > dwarf_psymtab_to_symtab() dwarfread.c#2417
 > psymtab_to_symtab_1() () dwarfread.c#2360
 > read_ofile_symtab() () dwarfread.c#2298
 > process_dies() () dwarfread.c#1965
 > read_file_scope() () dwarfread.c#1900
 > process_dies() () dwarfread.c#1982
 > read_structure_scope() () dwarfread.c#1145
 > struct_type() () dwarfread.c#1029             'mbr' o.k.
 > locval() () dwarfread.c#2155                  'loc' == 0
 > target_to_host() () dwarfread.c#3722          all params 0
 > bfd_getb16() libbfd.c#996                     'addr' == 0
 > 
 > the problem seems to be in struct_type(), the parameter 'mbr'
 > passed to locval() has mbr.at_location = 0, which is used inside
 > locval() where 'loc' is assigned 'dip->at_location'
 > which in turn is passed to target_to_host(loc,...).
 > 
 > In this example
 > the symbol behind 'mbr' is declared in an abstract class
 > as 'static const bool _USE_SANITY_CHECKS = true;
 > (but GDB will also not display other C++ files)
 > 
 > the contents of 'mbr' (struct dieinfo*) before the crash:
 > 
 > .die             = 0x40276b14
 > .die_length      = 89
 > .die_ref         = 3718248
 > .die_tag         = 13
 > at_padding       = 0
 > at_sibling       = 3718337
 > at_location      = 0
 > at_name          = "_USE_SANITY_CHECKS"
 > at_fund_type     = 0
 > at_mod_fund_type = 0x40276b37
 > ...
 > the rest of the elements all zero.
 > >How-To-Repeat:
 > Have an .ELF-file for the PPC compiled and linked with the
 > Diab compiler from C++ sources.
 > (Target not even needed)
 > Start the GDB
 > Load the symbol table:
 > (gdb) sym <xxx>.elf
 > Try to show a C++ source file:
 > (gdb) list <somefile>.cpp:1
 > 
 > Segmentation Fault
 > 
 > GDB crashes!
 > 
 > Assembler or C-files work o.k.
 > >Fix:
 > 
 > >Release-Note:
 > >Audit-Trail:
 > >Unformatted:
 > ----gnatsweb-attachment----
 > Content-Type: text/plain; name="gdb_bug.txt"
 > Content-Disposition: inline; filename="gdb_bug.txt"
 > 
 > OS Version:
 > ------------
 > Linux 2.4.18.4GB #1 Wed Mar 27 13:57:05 UTC 2002 i686 unknown
 > 
 > GNU Compiler:
 > -------------
 > gcc version 3.0.4 (SuSE)
 > 
 > 
 > GDB for PPC:
 > ------------
 > GNU gdb 5.3
 > ..
 > This GDB was configured as "--host=i686-pc-linux-gnu" --target="powerpc-860-elf".
 > 
 > 
 > Diab C++ Compiler:
 > ------------------
 > dcc Rel 4.3 Rev g
 > Copyright 1986-2000 Wind River Systems, Inc.
 > build date and time: Jul 27 2000 17:44:29
 > Table: PowerPC  Rel. 4.3g
 > 
 > 
 > 
 > 
 > 
 > We use GDB to cross-debug programs for a PPC target
 > (with a BDI2000 BDM box as remote target)
 > 
 > The software is compiled and linked into an ELF-file
 > with Diab's C++ compiler
 > 
 > We can run and step and set breakpoints in the target
 > alright, and we can load the symbols from the ELF-file.
 > 
 > But as soon as GDB wants to display a C++ source text,
 > it crashes with a Segmentation Fault, dumping the core.
 > 
 > 
 > Debugging the core dump got me the following backtrace
 > (I left out the first few lines)
 > 
 > backtrace:
 > 
 > ...
 > execute_command() top.c#711
 > cmd_func() cli-decode.c#1532
 > do_cfunc() cli-decode.c#53
 > line_info() source.c#1329
 > decode_line_spec_1() breakpoint.c#7481
 > decode_line_1() linespec.c#945
 > lookup_symtab() symtab.c#216
 > psymtab_to_symtab() symfile.c#375
 > dwarf_psymtab_to_symtab() dwarfread.c#2417
 > psymtab_to_symtab_1() () dwarfread.c#2360
 > read_ofile_symtab() () dwarfread.c#2298
 > process_dies() () dwarfread.c#1965
 > read_file_scope() () dwarfread.c#1900
 > process_dies() () dwarfread.c#1982
 > read_structure_scope() () dwarfread.c#1145
 > struct_type() () dwarfread.c#1029             'mbr' o.k.
 > locval() () dwarfread.c#2155                  'loc' == 0
 > target_to_host() () dwarfread.c#3722          all params 0
 > bfd_getb16() libbfd.c#996                     'addr' == 0
 > 
 > the problem seems to be in struct_type(), the parameter 'mbr'
 > passed to locval() has mbr.at_location = 0, which is used inside
 > locval() where 'loc' is assigned 'dip->at_location'
 > which in turn is passed to target_to_host(loc,...).
 > 
 > In this example
 > the symbol behind 'mbr' is declared in an abstract class
 > as 'static const bool _USE_SANITY_CHECKS = true;
 > (but GDB will also not display other C++ files)
 > 
 > the contents of 'mbr' (struct dieinfo*) before the crash:
 > 
 > .die             = 0x40276b14
 > .die_length      = 89
 > .die_ref         = 3718248
 > .die_tag         = 13
 > at_padding       = 0
 > at_sibling       = 3718337
 > at_location      = 0
 > at_name          = "_USE_SANITY_CHECKS"
 > at_fund_type     = 0
 > at_mod_fund_type = 0x40276b37
 > ...
 > the rest of the elements all zero.
 > 
 > 
 > Have an .ELF-file for the PPC compiled and linked with the
 > Diab compiler from C++ sources.
 > (Target not even needed)
 > Start the GDB
 > Load the symbol table:
 > (gdb) sym <xxx>.elf
 > Try to show a C++ source file:
 > (gdb) list <somefile>.cpp:1
 > 
 > Segmentation Fault
 > 
 > GDB crashes!
 > 
 > Assembler or C-files work o.k.
 > 
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]