This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: RFC c++ debugging thread
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Subject: Re: RFC c++ debugging thread
- From: Carlo Wood <carlo at alinoe dot com>
- Date: Sat, 30 Jun 2001 17:44:03 +0200
- Cc: libstdc++ at gcc dot gnu dot org
- References: <200106291900.f5TJ0YP01645@fillmore.constant.com>
On Fri, Jun 29, 2001 at 12:00:34PM -0700, Benjamin Kosnik wrote:
>
> Hey C++ people. The gdb folks are doing inventory on C++ support in
> the debugger. People who use gdb with C++ should probably scope this
> thread and add constructive comments:
>
> http://sources.redhat.com/ml/gdb/2001-06/msg00219.html
>
> -benjamin
If you can pass this on:
1) When typing expressions that have a scope, it is extremely annoying that the current
scope is often not known to gdb - especially the lack of namespace support is annoying.
I am using anonymous namespaces frequently and that makes it impossible to set
break-points other than by line number.
I think that when gdb is in a function 'A::(unamed)::C::f()', and I ask for 'g()', it should
use the same lookup as the compiler: "(gdb) b g" should set a break point in the same
function as that is called when I'd have had: "void A::(unnamed)::C::f(void) { g(); }".
The ideal situation being that using an expression that appears after a 'list' command
of the current scope will resolve to the correct expression. Another example being
that in my current project ALL code that I am debugging is in namespace 'libcw::debug',
so why do I constantly have to type: b 'libcw::debug::foo'? I'd like to just type:
"(gdb) b foo" (assuming the current code is in scope 'libcw::debug' thus).
2) The 'next' command often doesn't work: it just finishes the whole program. I therefore
have to use 'step' more often then I like, resulting in entering functions I don't
want to enter (like libstdc++/STL stuff). I don't know why/when this happens, but
it seems to happen often when returning from a function (on a '}' of a function that
I am exiting, I *always* type 's' to avoid losing the trace).
3) Often wrong source-file:line-numbers are given. This might be a bug in the compiler.
4) Not all mangled names are demangled, and obviously the qualifiers are demangled wrongly,
assuming you use libiberty's demangler then I suppose this will be fixed. I'll get back
to this after my own demangler finally works (I am working on getting adding of
substitutions right now).
Regards,
--
Carlo Wood <carlo@alinoe.com>