gdb bugs showing while working on libcwd

gdb bugs showing while working on libcwd

[Carlo Wood]

On Thu, May 23, 2002 at 09:45:27AM -0400, Liam Stewart wrote:
> Thanks for the info, Carlo. I'm going to CC this thread to the public
> gdb mailing list hosted at sources.redhat.com, if that's alright with
> you.

Weird, didn't find this mailinglist at first (a week ago thus).
Instead, I subscribed to 'bug-gdb@gnu.org'.

Anyway - here is the first problem.  Let me know if you can
reproduce it.

CVS Tag	: gdbbug00

$ cd libcwd
$ cvs update -r gdbbug00

Configuration: (its best to rerun bootstrap after a cvs update command).

$ ./bootstrap
$ CXX="g++-3.0.4" CC="gcc-3.0.4" ./configure --enable-maintainer-mode --enable-debug --enable-debugt --enable-debugm --disable-debug-output

[ Please note that "g++-3.0.4" is a script that I use
in order to make sure that the resulting applications
use the correct libstdc++ by adding
"-Wl,-rpath,/usr/local/gcc-3.0.4/lib:$LD_RUN_PATH"
to the commandline (where /usr/local/gcc-3.0.4)
is my installation prefix.  Alternatively you can
set LD_LIBRARY_PATH prior to run executables of course. ]

Next compile libcwd:

$ make

And a test application:

$ cd testsuite
$ make module_r.so
$ make threads_threads_shared

Next run threads_threads_shared (possibly a few times)
until it aborts.  For example:

~/c++/libcwd/testsuite>threads_threads_shared
1026       (0002) BAR     : Enabled
1026       (0002) BFD     : Disabled
1026       (0002) DEBUG   : Disabled
...
10251      (0011) COREDUMP: Deleting a marker must be done in the same "scope" as where it was allocated; for example, you cannot allocate marker A, then allocate marker B and then delete marker A before deleting first marker B.
...
Aborted

There should only be one 'COREDUMP' line and it should say
what it says here.  There can be any number of lines after
the coredump line before the application really aborts
however.

You now should have a core file.  Here is what I next do
what reveals a problem with gdb:

~/c++/libcwd/testsuite>gdb threads_threads_shared core.21920
GNU gdb Red Hat Linux (5.1-1)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or 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.
This GDB was configured as "i386-redhat-linux"...

warning: core file may not match specified executable file.
Core was generated by `threads_threads_shared'.
Program terminated with signal 6, Aborted.
Reading symbols from /home/carlo/c++/libcwd/.libs/libcwd_r.so.0...done.
Loaded symbols for /home/carlo/c++/libcwd/.libs/libcwd_r.so.0
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/local/gcc-3.0.4/lib/libstdc++.so.3...done.
Loaded symbols for /usr/local/gcc-3.0.4/lib/libstdc++.so.3
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/local/gcc-3.0.4/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/local/gcc-3.0.4/lib/libgcc_s.so.1
Reading symbols from /lib/libpthread.so.0...done.

warning: Unable to set global thread event mask: generic error
[New Thread 1024 (LWP 21868)]
Error while reading shared library symbols:
Can't attach LWP 21868: No such process
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x4034b171 in __kill () from /lib/libc.so.6
(gdb) bt
#0  0x4034b171 in __kill () from /lib/libc.so.6
#1  0x40315e42 in raise (sig=6) at signals.c:65
#2  0x4008167c in libcw::debug::core_dump() () at debug.cc:642
#3  0x40082d5c in libcw::debug::debug_tsd_st::finish(libcw::debug::debug_ct&, libcw::debug::channel_set_data_st&, libcw::debug::_private_::TSD_st&) (this=0x82249a8, debug_object=@0x80842a8, channel_set=@0xbe5ff90c, __libcwd_tsd=@0x80877e4) at debug.cc:1014
#4  0x400831e3 in libcw::debug::debug_tsd_st::fatal_finish(libcw::debug::debug_ct&, libcw::debug::channel_set_data_st&, libcw::debug::_private_::TSD_st&) (this=0x82249a8, debug_object=@0x80842a8, channel_set=@0xbe5ff90c, __libcwd_tsd=@0x0) at debug.cc:1104
#5  0x40091c24 in libcw::debug::marker_ct::~marker_ct() (this=0x834e530) at debugmalloc.cc:2301
#6  0x0806a32e in leak_prog(void*) () at libcwd.tst/leak.cc:145
#7  0x4031308b in pthread_start_thread (arg=0xbe5ffbe0) at manager.c:284
(gdb)  thread
[Current thread is 1 (process 21920)]
(gdb) thread 2
Couldn't get registers: No such process.
(gdb) thread 1
Couldn't get registers: No such process.
(gdb)

The bug is that after trying 'thread 2', there is no
way to return to 'thread 1' again.

If you have "problems" with the fact that I am using
gdb 5.1, then I am willing to use 5.2 or the latest
cvs version; I tried that before however and it was
totally unusable... so the problems with that will
be different ;).

-- 
Carlo Wood <carlo@alinoe.com>

Re: gdb bugs showing while working on libcwd

[Daniel Jacobowitz]

On Fri, May 24, 2002 at 02:35:46AM +0200, Carlo Wood wrote:
> You now should have a core file.  Here is what I next do
> what reveals a problem with gdb:
> 
> ~/c++/libcwd/testsuite>gdb threads_threads_shared core.21920
> GNU gdb Red Hat Linux (5.1-1)
> Copyright 2001 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or 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.
> This GDB was configured as "i386-redhat-linux"...
> 
> warning: core file may not match specified executable file.
> Core was generated by `threads_threads_shared'.
> Program terminated with signal 6, Aborted.
> Reading symbols from /home/carlo/c++/libcwd/.libs/libcwd_r.so.0...done.
> Loaded symbols for /home/carlo/c++/libcwd/.libs/libcwd_r.so.0
> Reading symbols from /lib/libdl.so.2...done.
> Loaded symbols for /lib/libdl.so.2
> Reading symbols from /usr/local/gcc-3.0.4/lib/libstdc++.so.3...done.
> Loaded symbols for /usr/local/gcc-3.0.4/lib/libstdc++.so.3
> Reading symbols from /lib/libm.so.6...done.
> Loaded symbols for /lib/libm.so.6
> Reading symbols from /usr/local/gcc-3.0.4/lib/libgcc_s.so.1...done.
> Loaded symbols for /usr/local/gcc-3.0.4/lib/libgcc_s.so.1
> Reading symbols from /lib/libpthread.so.0...done.
> 
> warning: Unable to set global thread event mask: generic error
> [New Thread 1024 (LWP 21868)]

This specific bug is, however, fixed in GDB 5.2.  It won't help much. 
You are trying to debug a multithreaded application via core dump; only
via my or Mark Gross at Intel's patches does Linux dump enough
information to core files in order to see threads there.  You can find
them in the archives of the linux-kernel list.

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

Re: Huge problems with debugging threaded C++ programs

[Liam Stewart]

On Thu, May 23, 2002 at 03:38:16PM +0200, Carlo Wood wrote:
> 
> Let me state (again, but in more detail) what is the issue:
> 
> I run into gdb bugs very often, but can't make simple test
> cases for them - and thus never reported any of them.
> 
> I think that the only way for you to reproduce the problems
> is to install the same development environment as I have
> and simply reproduce the exact same situation.
> 
> My proposal is that you will install this environment; I will
> then commit my work the cvs repository of my project using
> incremental tags for every problem I run into, and mail you
> the tag and how to reproduce the problem.
> 
> The problems that I posted before can not be reproduced because
> I did not add tags thus far.
> 
> I propose you first put some time into installing the whole
> developing environment that I am working with.
> 
> In order to do this you will need a i686 running linux.
> (I am using an Athlon, but I think any i686 will do).
> 
> I am using kernel 2.4.18; I am not sure things will be too
> different if you'd use a 2.5 kernel, or a 2.2 kernel - but
> you could try just using what you have.  A difference might
> be caused by the fact that I am currently testing threaded
> applications and every tiny little change has effect on
> the program flow.
> 
> I am using RedHat here, and thus use rpms.  I have installed the
> glibc-2.2.4-19.3 rpm, but I am afraid I compiled it myself.
> Perhaps I should send you my rpm so you will be sure that
> your glibs is the same.  As far as I remember, the only
> difference is that I enabled debugging (so I can use gdb
> to trace into libc) and that I have the source code installed
> for that purpose.

What version of Red Hat Linux?

> Having the source code installed for glibc is important I am
> afraid (at least, for me, to find bugs in libcwd).
> 
> Finally, you should install the project that I am working on:
> 
> cvs -d:pserver:anonymous@cvs.libcwd.sourceforge.net:/cvsroot/libcwd login
> 
> (press enter on the password prompt)
> 
> cvs -z3 -d:pserver:anonymous@cvs.libcwd.sourceforge.net:/cvsroot/libcwd co libcwd
> 
> cd libcwd
> ./bootstrap
> 
> 'bootstrap' will probably flood you with demands to install things
> and/or upgrade things; please follow the instructions.
> 
> Finally you should have installed the release version of gcc-3.0.4
> and the corresponding g++.  You can install those seperately
> (not as default compiler).  If you don't have this installed already
> or know how to do it quickly then please tell me and I'll send you
> two scripts that makes installing new compiler versions very easy
> (I am using 11 different versions at the same time).
> 
> Please read the INSTALL file of the libcwd project for detailed
> information about what you need to install to compile things, to
> run ./bootstrap but also in order to run the testsuite.
> Probably you won't need to be able to run the testsuite in order
> to reproduce the problems that I am running into though.
> 
> Let me know if there are any problems.

None so far..

> 
> -- 
> Carlo Wood <carlo@alinoe.com>
> 
> PS I did not 'cvs commit' the most recent changes yet.

-- 
Liam Stewart :: Red Hat Canada, Ltd. :: liams@redhat.com

gdb bugs showing while working on libcwd

[Carlo Wood]

On Fri, May 24, 2002 at 11:41:49AM -0400, Liam Stewart wrote:
> What version of Red Hat Linux?

I installed things manually so much that you can't talk
about a version anymore.  You'll have to ask for specific
versions of tools/libraries that are significant.

The last time I did a full sync was with RH7.2, but I have
installed many many many things from rawhide, and the most
important things like glibc, kernel, compilers and libraries
are not related to any release (they are newer).

> > Let me know if there are any problems.
> None so far..

Good.  I just released version 0.99.20, but you'll get updated
automatically when I post the next 'tag' anyway, so I guess
that is not relevant ;).

The first thing I will do now is patch my kernel so it
will dump cores that are as useful as possible, and then
I'll start to use the latest CVS version of gdb and see
what happens.

Please get back to me asap if you don't want me to patch
my kernel because that wouldn't be representative enough
or because you can't patch your kernel likewise (something
that I suppose is needed in order to mirror what I do here),
or when you want me to use the released gdb 5.2 rather
than the current cvs version.

-- 
Carlo Wood <carlo@alinoe.com>

PS My software efforts aim at developers that are willing
   to live on the bleeding edge.  Although I didn't yet
   *demand* that everyone uses g++-3.1, I CAN demand that
   they patch their kernel when that is the only way to
   work reasonable with gdb (and obviously, my library
   doesn't make gdb redundant but on the contrary is
   relatively useless in an environment where gdb doesn't
   work well, because then you still can't debug, now
   can you!? ;).

Re: gdb bugs showing while working on libcwd

[Carlo Wood]

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:

~/c++/libcwd/testsuite>gdb tst_alloctag_shared
GNU gdb 2002-05-25-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or 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.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) b main
Breakpoint 1 at 0x80521cd: file libcwd.tst/alloctag.cc, line 25.
(gdb) r
Starting program: /home/carlo/c++/libcwd/testsuite/tst_alloctag_shared

Breakpoint 1, main () at libcwd.tst/alloctag.cc:25
25        Debug( check_configuration() );
(gdb) b debugmalloc.cc:1197
Breakpoint 2 at 0x4007b660: file debugmalloc.cc, line 1197.
(gdb) c
Continuing.
BFD     : Disabled
DEBUG   : Disabled
MALLOC  : Enabled
NOTICE  : Enabled
SYSTEM  : Enabled
WARNING : Enabled
MALLOC  : operator new[] (size = 50) = 0x81d1b28
MALLOC  : operator new (size = 4) = 0x81d1c08
MALLOC  : malloc(33) = 0x805f260
MALLOC  : malloc(55) = 0x807df90
MALLOC  : calloc(22, 10) = 0x80cbab8
MALLOC  : calloc(55, 10) = 0x8066028
MALLOC  : malloc(11) = 0x81d2990
MALLOC  : realloc(0x81d2990, 1000) = 0x80664a8
MALLOC  : malloc(66) = 0x814dfa0
MALLOC  : realloc(0x814dfa0, 1000) = 0x8066a58
MALLOC  : Allocated memory: 2912 bytes in 8 blocks.

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 Wood <carlo@alinoe.com>

Re: gdb bugs showing while working on libcwd

[Daniel Jacobowitz]

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

Re: gdb bugs showing while working on libcwd

[Carlo Wood]

Ok, got a new one.

$ cd libcwd
$ cvs update -r gdbbug02
$ ./bootstrap
$ CXX="g++-3.1" CC="gcc-3.1" ./configure --enable-maintainer-mode --enable-debug --enable-debugt --enable-debugm --disable-debug-output
$ make
$ cd testsuite
$ make module_r.so
$ make threads_threads_shared
$ ./threads_threads_shared

Then I get:

~/c++/libcwd/testsuite>gdb threads_threads_shared core*
GNU gdb 2002-05-25-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or 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.
This GDB was configured as "i686-pc-linux-gnu"...

warning: core file may not match specified executable file.
Core was generated by `threads_threads_shared'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /home/carlo/c++/libcwd/.libs/libcwd_r.so.0...done.
Loaded symbols for /home/carlo/c++/libcwd/.libs/libcwd_r.so.0
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/local/gcc-3.1/lib/libstdc++.so.4...done.
Loaded symbols for /usr/local/gcc-3.1/lib/libstdc++.so.4
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/local/gcc-3.1/lib/libgcc_s.so.1...done.
Loaded symbols for /usr/local/gcc-3.1/lib/libgcc_s.so.1
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x40078d3f in libcw::debug::debug_tsd_st::start(libcw::debug::debug_ct&, libcw::debug::channel_set_data_st&, libcw::debug::_private_::TSD_st&) (this=0x0, debug_object=@0x8074be8, channel_set=@0xbf7ff82c, __libcwd_tsd=@0x8075968) at debug.cc:801
801           LIBCWD_ASSERT( tsd_initialized );
(gdb) up
#1  0x4007bdd0 in libcw::debug::_private_::assert_fail(char const*, char const*, int, char const*) (
    expr=0x400bd160 "!__libcwd_tsd.internal || __libcwd_tsd.cancel_explicitely_disabled || __libcwd_tsd.cancel_explicitely_deferred",
    file=0x400bcdb5 "debugmalloc.cc", line=1894, function=0x400be980 "void* libcw::debug::_private_::new_memblk_map()") at debug.cc:1603
1603            DoutFatal(dc::core, file << ':' << line << ": " << function << ": Assertion `" << expr << "' failed.\n");
(gdb) p __libcwd_tsd
$1 = (TSD_st &) @0x8075968: {internal = 1, library_call = 0, inside_malloc_or_free = 0, memblk_map = 0x0, marker = 0,
  recursive_fatal = false, recursive_assert = true, cancel_explicitely_deferred = 0, cancel_explicitely_disabled = 0,
  inside_critical_area = 0, cleanup_handler_installed = 0, internal_debugging_code = 1, tid = 1026, do_off_array = {0, 0, 0, 0, 0, 0, 0, 0},
  do_array = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, off_cnt_array = {0 <repeats 256 times>}, static S_exit_key = Internal: global symbol `_ZN5libcw5debug9_private_6TSD_st10S_exit_keyE' found in threading.cc psymtab but not in symtab.
_ZN5libcw5debug9_private_6TSD_st10S_exit_keyE may be an inlined function, or may be a template function
(if a template, try specifying an instantiation: _ZN5libcw5debug9_private_6TSD_st10S_exit_keyE<type>).
(gdb)

_ZN5libcw5debug9_private_6TSD_st10S_exit_keyE

is

libcw::debug::_private_::TSD_st::S_exit_key

A static member of struct TSD_st (in namespace
libcw::debug::_private_) of type pthread_key_t.

Hence, it is NOT a inlined function (or a function at all),
nor is it a template.  It is also very surely instantiated ;).

Don't tell me this is related to namespaces too :/

-- 
Carlo Wood <carlo@alinoe.com>

Re: gdb bugs showing while working on libcwd

[Daniel Jacobowitz]

On Mon, May 27, 2002 at 03:42:55AM +0200, Carlo Wood wrote:
> (gdb) p __libcwd_tsd
> $1 = (TSD_st &) @0x8075968: {internal = 1, library_call = 0, inside_malloc_or_free = 0, memblk_map = 0x0, marker = 0,
>   recursive_fatal = false, recursive_assert = true, cancel_explicitely_deferred = 0, cancel_explicitely_disabled = 0,
>   inside_critical_area = 0, cleanup_handler_installed = 0, internal_debugging_code = 1, tid = 1026, do_off_array = {0, 0, 0, 0, 0, 0, 0, 0},

>   do_array = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, off_cnt_array = {0 <repeats 256 times>}, static S_exit_key = Internal: global symbol `_ZN5libcw5debug9_private_6TSD_st10S_exit_keyE'


**
>found in threading.cc psymtab but not in symtab.
**

> _ZN5libcw5debug9_private_6TSD_st10S_exit_keyE may be an inlined function, or may be a template function
> (if a template, try specifying an instantiation: _ZN5libcw5debug9_private_6TSD_st10S_exit_keyE<type>).
> (gdb)
> 
> _ZN5libcw5debug9_private_6TSD_st10S_exit_keyE
> 
> is
> 
**
> libcw::debug::_private_::TSD_st::S_exit_key
**

> A static member of struct TSD_st (in namespace
> libcw::debug::_private_) of type pthread_key_t.
> 
> Hence, it is NOT a inlined function (or a function at all),
> nor is it a template.  It is also very surely instantiated ;).
> 
> Don't tell me this is related to namespaces too :/

[** Emphasis ** mine **]

Of course it is; it's in a namespace.  Really, I don't expect any of
what you're doing to work right now.  My first stab at fixing it was a
complete disaster, too...

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

Re: gdb bugs showing while working on libcwd

[Carlo Wood]

On Mon, May 27, 2002 at 02:03:29AM -0400, Daniel Jacobowitz wrote:
> Of course it is; it's in a namespace.  Really, I don't expect any of
> what you're doing to work right now.  My first stab at fixing it was a
> complete disaster, too...

That would make sense if NOTHING worked that was in a namespace.
But in many cases it does.  I trust you if think this is related
to namespaces being unsupported, but never say 'of course'.

Because the whole standard resides in std::, this must be the
reason that gdb is virtually unusable with C++ :/

(gdb) p result
$2 = {static npos = Cannot access memory at address 0x8416bc4

(gdb) p buf
$1 = {<basic_iostream<char,std::char_traits<char> >> = {<basic_istream<char,std::char_traits<char> >> =
{<basic_ios<char,std::char_traits<char> >> = {<ios_base> = {static boolalpha = Cannot access memory at address 0x0

But if you ask me, it is more related to static members than
to namespaces...

-- 
Carlo Wood <carlo@alinoe.com>

Re: gdb bugs showing while working on libcwd

[Daniel Jacobowitz]

On Mon, May 27, 2002 at 02:42:20PM +0200, Carlo Wood wrote:
> On Mon, May 27, 2002 at 02:03:29AM -0400, Daniel Jacobowitz wrote:
> > Of course it is; it's in a namespace.  Really, I don't expect any of
> > what you're doing to work right now.  My first stab at fixing it was a
> > complete disaster, too...
> 
> That would make sense if NOTHING worked that was in a namespace.
> But in many cases it does.  I trust you if think this is related
> to namespaces being unsupported, but never say 'of course'.
> 
> Because the whole standard resides in std::, this must be the
> reason that gdb is virtually unusable with C++ :/
> 
> (gdb) p result
> $2 = {static npos = Cannot access memory at address 0x8416bc4
> 
> (gdb) p buf
> $1 = {<basic_iostream<char,std::char_traits<char> >> = {<basic_istream<char,std::char_traits<char> >> =
> {<basic_ios<char,std::char_traits<char> >> = {<ios_base> = {static boolalpha = Cannot access memory at address 0x0
> 
> But if you ask me, it is more related to static members than
> to namespaces...

Here's my understanding:

For a lot of operations, we operate by looking up the demangled name in
a table of demanglings of the binary's symbols.  It may not behave
precisely right, because we lose some type information, but things
mostly work.  For some other operations, we try to behave correctly by
using the symbol table constructed from debug information; it's in that
latter case that we lose it.


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

Re: gdb bugs showing while working on libcwd

[Carlo Wood]

On Mon, May 27, 2002 at 02:04:51PM -0400, Daniel Jacobowitz wrote:
> mostly work.  For some other operations, we try to behave correctly by
> using the symbol table constructed from debug information; it's in that
> latter case that we lose it.

Is there any way I might help?  What exactly is going wrong
in that latter case?

Note that I wrote a demangler as well as a dwarf2 and stabs
debug symbols reader, so I might have some useful experience.

-- 
Carlo Wood <carlo@alinoe.com>

Re: gdb bugs showing while working on libcwd

[Daniel Jacobowitz]

On Tue, May 28, 2002 at 02:01:01AM +0200, Carlo Wood wrote:
> On Mon, May 27, 2002 at 02:04:51PM -0400, Daniel Jacobowitz wrote:
> > mostly work.  For some other operations, we try to behave correctly by
> > using the symbol table constructed from debug information; it's in that
> > latter case that we lose it.
> 
> Is there any way I might help?  What exactly is going wrong
> in that latter case?
> 
> Note that I wrote a demangler as well as a dwarf2 and stabs
> debug symbols reader, so I might have some useful experience.

Basically, we need to change how we store symbol information.  It's not
flexible to account for multiple namespaces.  There's quite a bit in
the archives about it if I recall correctly...

By the way, if that includes a v3 demangler - there are three failures
in the demangler testsuite on v3 for functions taking function pointers
that I can't wrap my head around... :)

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

Re: gdb bugs showing while working on libcwd

[Carlo Wood]

On Tue, May 28, 2002 at 04:16:56AM -0400, Daniel Jacobowitz wrote:
> By the way, if that includes a v3 demangler - there are three failures
> in the demangler testsuite on v3 for functions taking function pointers
> that I can't wrap my head around... :)

Would replacing __cxa_demangle in libiberty with a demangler
that does v3 demangling (and only v3 demangling) do the job?
I am not familiar with this libiberty interface that seems
to support a dozen different mangling styles.

-- 
Carlo Wood <carlo@alinoe.com>

Re: gdb bugs showing while working on libcwd

[Daniel Jacobowitz]

On Tue, May 28, 2002 at 02:50:20PM +0200, Carlo Wood wrote:
> On Tue, May 28, 2002 at 04:16:56AM -0400, Daniel Jacobowitz wrote:
> > By the way, if that includes a v3 demangler - there are three failures
> > in the demangler testsuite on v3 for functions taking function pointers
> > that I can't wrap my head around... :)
> 
> Would replacing __cxa_demangle in libiberty with a demangler
> that does v3 demangling (and only v3 demangling) do the job?
> I am not familiar with this libiberty interface that seems
> to support a dozen different mangling styles.

The v3 code is completely separate; it's off in cp-demangle.c rather
than cplus-dem.c (or reversed).  The original demangler just calls the
v3 demangler when necessary, so it doesn't come in to this at all.

I was just hoping someone more familiar than I with the mangling scheme
could look at the existing one and figure out where the shortcoming
is...

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

Re: gdb bugs showing while working on libcwd

[Carlo Wood]

On Tue, May 28, 2002 at 01:37:46PM -0400, Daniel Jacobowitz wrote:
> I was just hoping someone more familiar than I with the mangling scheme
> could look at the existing one and figure out where the shortcoming
> is...

The problem is probably a design issue and it will be
a lot easier to just completely replace the demangler
with mine.  Fixing the existing demangler is not a matter
of changing a few lines.

I've been asked before to donate my demangler to gdb,
someone translated it to C and then lost the code again
(I wrote it in C++).  I've also been asked to donate
the demangler to libiberty (by the libstdc++/g++ people)
but there where some legal issues... its stupid, the FSF
makes it some times impossible to donate code it seems
(at least in my case).  If one has to sign something
before they want to use code then what is the GPL
license good for?  What about all those people
who use the GPL but never bother to gather signatures
from all over the world?  The "problem" is that
Carlo Wood is not my real name, and although I am
willing to sign anything and donate anything under the
GPL, I do NOT want my real name somewhere on the web
or in a searchable database.  Now EVERYTIME (and this
has come up at least three times very very seriously
in the past 8 years) I make a lot of effort to get
things arranged, people fail on me and nothing happens.
This time I am AGAIN waiting already several months
for the response of someone (I just want an 'ok, we
won't publish your real name)... Blah.  No code then.

But in the meantime *I*'d like a working demangler
in libiberty as well actually, grrrmmbl.

Annoyed,

-- 
Carlo Wood <carlo@alinoe.com>