More C++ debugging comments

More C++ debugging comments

[Jim Blandy]

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 <bkoz@redhat.com>
To: jimb@redhat.com
Subject: Re: RFC c++ debugging thread (fwd)
Message-ID: <Pine.SOL.3.91.1010702120615.3597C-100000@taarna.cygnus.com>


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


------- End of forwarded message -------

Re: More C++ debugging comments

[Daniel Berlin]

However, it would require significant rework of the debugger to support it.
And some compiler work too.
This is because by the time we go to output debugging info, using decls 
don't exist. The symbols they make visible, etc, have just been put in all 
the right places.
However, this means we don't know *what* the user actually said (I.E. 
"using namespace std;"), we only know the result.
I was more concerned with the scoping issue than anything else.

I can create symbols for namespaces if it helps, too (We always get these 
"no symbol named "A" in current context" where A is a namespace, since 
symbols don't exist for them).


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

>
> 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 <bkoz@redhat.com>
> To: jimb@redhat.com
> Subject: Re: RFC c++ debugging thread (fwd)
> Message-ID: <Pine.SOL.3.91.1010702120615.3597C-100000@taarna.cygnus.com>
>
>
> 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 <carlo@alinoe.com>
> 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). 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>
>
>
> ------- End of forwarded message -------

Re: More C++ debugging comments

[Jim Blandy]

Daniel Berlin <dan@cgsoftware.com> writes:
> However, it would require significant rework of the debugger to support it.
> And some compiler work too.

Can Dwarf2.1 carry the necessary information?

I'm happy to rework the debugger's symbol tables as needed to make
this stuff work.  But we need the right info from the compiler first.

> I can create symbols for namespaces if it helps, too (We always get these 
> "no symbol named "A" in current context" where A is a namespace, since 
> symbols don't exist for them).

The more information, the better, I'd say.

Re: More C++ debugging comments

[Daniel Berlin]

Jim Blandy <jimb@zwingli.cygnus.com> writes:

> Daniel Berlin <dan@cgsoftware.com> writes:
>> However, it would require significant rework of the debugger to support it.
>> And some compiler work too.
> 
> Can Dwarf2.1 carry the necessary information?
Yes.
Easily.

> 
> I'm happy to rework the debugger's symbol tables as needed to make
> this stuff work.  But we need the right info from the compiler
> first.

You do, of course, realize that the reason the compiler has been
waiting to emit the right info is because the debugger hasn't
supported it yet.
It's a vicious cycle.
Unless it's the same person doing the work on both side, people tend
to either miss that the compiler is waiting on the debugger, or vice
versa.
We need some sort of official liasion or something.
Or maybe something that is subscribed to gcc-cvs, that when it
receives a commit message on *out.c (dbxout,dwarf2out,etc), forwards
it to a gdb list.

Considering how often these files are touched, and the fact that the
files *only* concern debug output, I don't think false positives would
be an issue.

Of course, this would only tell us when gcc has already changed, not
what hasn't been implemented because someone was waiting for the
debugger to do it.
> 
>> I can create symbols for namespaces if it helps, too (We always get these 
>> "no symbol named "A" in current context" where A is a namespace, since 
>> symbols don't exist for them).
> 
> The more information, the better, I'd say.
Okeydokey.



-- 
"Curiosity killed the cat, but for a while I was a suspect.
"-Steven Wright