Re: gdb bugs showing while working on libcwd

[Daniel Jacobowitz <drow@mvista.com>]

On Sat, May 25, 2002 at 03:33:02AM +0200, Carlo Wood wrote:
> I couldn't find the kernel patch to dump multithreaded cores yet,
> but I installed gdb from cvs, and it seems to work now :).
> 
> Ok, so lets start with one of the problems I did run into
> most frequently, something that I could therefore reproduce
> easily and what shouldn't give you any problems to reproduce
> either:
> 
> $ cd libcwd
> $ cvs update -r gdbbug01
> $ ./bootstrap
> $ CXX="g++-3.0.4" CC="gcc-3.0.4" ./configure --enable-maintainer-mode --enable-debug --enable-debugt --enable-debugm --disable-debug-output
> $ make
> $ cd testsuite
> $ make tst_alloctag_shared
> 
> Then I get:

> Breakpoint 2, libcw::debug::dm_alloc_copy_ct::show_alloc_list(int, libcw::debug::channel_ct const&, libcw::debug::ooam_filter_ct const&) const (this=0x8066980, depth=1, channel=@0x400d4954, filter=@0xbffff540) at debugmalloc.cc:1197
> 1197        const_cast<location_ct*>(&alloc->location())->handle_delayed_initialization();
> (gdb) p this
> $1 = (dm_alloc_copy_ct *) 0x8066980
> (gdb) p *this
> Value can't be converted to integer.
> 
> 
> The problem here is that apparently gdb doesn't know
> the definition of class dm_alloc_copy_ct.  It should
> know that imho.

Carlo,

That's because you're using namespaces.  GDB has negligible support for
namespaces right now; we know this far too well.  Jim and I have been
discussing plans of attack on this for some time; the only way to do it
properly involves some significant architectural changes to the way GDB
processes symbol tables, and Jim (and I) got distracted in the middle
of our last conversation about this.  It will definitely take some
time.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer