From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: gdb@sources.redhat.com Subject: More C++ debugging comments Date: Mon, 02 Jul 2001 16:13:00 -0000 Message-id: X-SW-Source: 2001-07/msg00003.html Note that the first problem he mentions has to do with namespaces. I'll ask him for test cases for the rest. ------- Start of forwarded message ------- Date: Mon, 2 Jul 2001 12:06:33 -0700 (PDT) From: Benjamin Kosnik To: jimb@redhat.com Subject: Re: RFC c++ debugging thread (fwd) Message-ID: can't see to get these c++ people to post on gdb's list... ---------- Forwarded message ---------- Date: Sat, 30 Jun 2001 17:44:03 +0200 From: Carlo Wood To: Benjamin Kosnik Cc: libstdc++@gcc.gnu.org Subject: Re: RFC c++ debugging thread 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 ------- End of forwarded message -------