Re: RFC c++ debugging thread (fwd)

[Daniel Berlin <dan at cgsoftware dot com>]

--On Monday, July 02, 2001 6:19 PM -0500 Jim Blandy 
<jimb@zwingli.cygnus.com> wrote:

>
> Hi, Carlo.  Ben Kosnik forwarded your message to me.  I've taken the
> liberty of CC'ing the GDB discussion mailing list on this reply; hope
> that's okay.
>
>> ---------- Forwarded message ----------
>> Date: Sat, 30 Jun 2001 17:44:03 +0200
>> From:
>> To: Benjamin Kosnik <bkoz@redhat.com>
>> 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).
>
> Our current understanding is that the namespace lossage is the most
> immediately annoying problem, so that's what we'd like to fix first.
In particular, though, his case is not easy to fix, without reworking gdb's 
symbol table, and gcc.
We don't track what the current scope really is, only what the current 
function really is (Which isn't necessarily the scope, the scope includes 
what is *visible* from that function, which is the part we miss).

On the GCC side, this is because, as I just emailed you, by the time we do 
debug output, we don't have using decl's anymore, only their results.  And 
even then, we have the final view of a namespace (AFAIK, I could be wrong 
on this point, but when i just was implementing the namespace support, this 
is the distinct feeling i got from looking at what was given to the dwarf2 
outputter)
So this one is a little tricky.

>
> We have test cases for some problems, and although your problem sounds
> similar, I can't be sure it's exactly the same problem you are seeing.
> Could you put together a test case, show us what GDB does, and tell us
> what you wish it did?  Post to gdb@sources.redhat.com.
>
>> 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).

GCC bug.

>> 3) Often wrong source-file:line-numbers are given.  This might be a bug
>> in the compiler.
Ditto.
> 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).
>
> Again, these sound like something we know about, but I'm not sure.  If
> you can provide a test case, that makes it much easier for us to be
> sure we've actually fixed what's bothering you.

Carlo, in number 4, is referring to some weird placement of qualifiers 
(const, volatile, etc) in some demangled names.
Nobody has had time to actually fix the demangler yet, since it's purely 
cosmetic.
Me, i'm waiting for him to post his demangler source on the libcw cvs, and 
i'll do the necessary rewrites in the demangler.