Re: GDB C++ support

Re: GDB C++ support

[Michael Elizabeth Chastain]

Sheesh, Eli.  Guido asked:

gs> So my question would be, how far the work on support for C++ and gcc 3.x
gs> went as of now, and if one could expect some solution to this problem in the
gs> near future?
gs> 
gs> It just confuses me, that the development of gcc and gdb seems so
gs> asynchronous, and a compiler suite, as elegant as it may be, withers away if
gs> it lacks usable debugging support.

And that's what I answered, especially the second part.

eli> Do you (or someone else) happen to know whether v5.1 solves some or
eli> all of the specific problems Guido described in his message?  If not,
eli> he has no reason to try GDB 5.1, does he?

Well, gdb 5.0 was released more than a year before gcc 3.0, and gdb 5.1
was released more than 5 months after gcc 3.0.  That's a good reason
to expect that gdb 5.1 will work a lot better than gdb 5.0 when the
target program is compiled with gcc 3.0.3.

I don't have gcc 3.0.3 installed yet (I wish I did).  I don't have
djgpp 2.03 installed (I probably never will).  And I don't have time
to chase after user bug reports with incomplete source code and gdb 5.0.

Michael C

Re: GDB C++ support

[Eli Zaretskii]

> Date: Tue, 15 Jan 2002 07:57:32 -0600
> From: Michael Elizabeth Chastain <mec@shout.net>
> 
> eli> Do you (or someone else) happen to know whether v5.1 solves some or
> eli> all of the specific problems Guido described in his message?  If not,
> eli> he has no reason to try GDB 5.1, does he?
> 
> Well, gdb 5.0 was released more than a year before gcc 3.0, and gdb 5.1
> was released more than 5 months after gcc 3.0.  That's a good reason
> to expect that gdb 5.1 will work a lot better than gdb 5.0 when the
> target program is compiled with gcc 3.0.3.

Yes, the principles are well understood.

> I don't have gcc 3.0.3 installed yet (I wish I did).  I don't have
> djgpp 2.03 installed (I probably never will).  And I don't have time
> to chase after user bug reports with incomplete source code and gdb 5.0.

You don't need to apologize about not having the information I asked
for.  But there's no need to be harsh, either.  Guido wanted to get
specific help for his specific problem; if no one has the answer, then
the ensuing silence will be self-explanatory ;-)

(Btw, there's nothing DJGPP-specific in what Guido asked: DJGPP
supports both stabs and DWARF2 debugging, so if someone can answer the
questiions for GNU/Linux, say, they will be good for DJGPP as well.)

TIA

Re: GDB C++ support

[Jim Ingham]

Eli,

It does know how to demangle gcc 3.0 style names, at least.  Just for 
that it is worth getting...

Jim

>
>
>
> On Mon, 14 Jan 2002, Michael Elizabeth Chastain wrote:
>
>> So try gdb 5.1.  It works much better with gcc 3 versions.
>
> Do you (or someone else) happen to know whether v5.1 solves some or
> all of the specific problems Guido described in his message?  If not,
> he has no reason to try GDB 5.1, does he?
>
> I've seen too many messages here which describe problems GDB 5.1 has
> debugging C++ code, and I know too little about these problems to tell
> whether they are relevant to Guido's case.  That's why I suggested him
> to write here, hoping that someone could provide a more specific
> answer.
>
>
>
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer

Re: GDB C++ support

[Michael Elizabeth Chastain]

eli> You don't need to apologize about not having the information I asked
eli> for.  But there's no need to be harsh, either.

Yeah, you're right, I got up grouchy this morning.  I apologize for that.

Co-incidentally, I'm making test runs with stock 5.1 right now.
Here's an excerpt from gdb.log:

  # gdb 5.1, gcc 3.0.2, -gdwarf-2, gdb.c++/method.exp

  (gdb) break main^M
  Breakpoint 1 at 0x8048549: file /berman/migchain/source/gdb-5.1/gdb/testsuite/gdb.c++/method.cc, line 66.^M
  (gdb) run ^M
  Starting program: /berman/migchain/build/native/gdb-5.1/gdb/testsuite/gdb.c++/method ^M
  ^M
  Breakpoint 1, main () at /berman/migchain/source/gdb-5.1/gdb/testsuite/gdb.c++/method.cc:66^M
  66        k = 10;^M
  (gdb) break A::foo^M
  Breakpoint 2 at 0x80484a6: file /berman/migchain/source/gdb-5.1/gdb/testsuite/gdb.c++/method.cc, line 38.^M
  (gdb) PASS: gdb.c++/method.exp: set breakpoint on A::foo
  continue^M
  Continuing.^M
  ^M
  Breakpoint 2, A::foo(int) (this=0xbffff0e0, arg=13) at /berman/migchain/source/gdb-5.1/gdb/testsuite/gdb.c++/method.cc:38^M
  38        x += arg;^M
  (gdb) FAIL: gdb.c++/method.exp: continuing and breaking in A::foo

So you can see that 'break A::foo' works and gdb takes the breakpoint.
I don't know what that "FAIL" is about (that is a different issue).

Constructively,

Michael C

Re: GDB C++ support

[Eli Zaretskii]

> Date: Tue, 15 Jan 2002 11:48:34 -0600
> From: Michael Elizabeth Chastain <mec@shout.net>
> 
> So you can see that 'break A::foo' works and gdb takes the breakpoint.

Thanks, this is exactly what I wanted to know.

Re: GDB C++ support

[Daniel Jacobowitz]

On Tue, Jan 15, 2002 at 11:48:34AM -0600, Michael Elizabeth Chastain wrote:
> eli> You don't need to apologize about not having the information I asked
> eli> for.  But there's no need to be harsh, either.
> 
> Yeah, you're right, I got up grouchy this morning.  I apologize for that.
> 
> Co-incidentally, I'm making test runs with stock 5.1 right now.
> Here's an excerpt from gdb.log:
> 
>   # gdb 5.1, gcc 3.0.2, -gdwarf-2, gdb.c++/method.exp
> 
>   (gdb) break main^M
>   Breakpoint 1 at 0x8048549: file /berman/migchain/source/gdb-5.1/gdb/testsuite/gdb.c++/method.cc, line 66.^M
>   (gdb) run ^M
>   Starting program: /berman/migchain/build/native/gdb-5.1/gdb/testsuite/gdb.c++/method ^M
>   ^M
>   Breakpoint 1, main () at /berman/migchain/source/gdb-5.1/gdb/testsuite/gdb.c++/method.cc:66^M
>   66        k = 10;^M
>   (gdb) break A::foo^M
>   Breakpoint 2 at 0x80484a6: file /berman/migchain/source/gdb-5.1/gdb/testsuite/gdb.c++/method.cc, line 38.^M
>   (gdb) PASS: gdb.c++/method.exp: set breakpoint on A::foo
>   continue^M
>   Continuing.^M
>   ^M
>   Breakpoint 2, A::foo(int) (this=0xbffff0e0, arg=13) at /berman/migchain/source/gdb-5.1/gdb/testsuite/gdb.c++/method.cc:38^M
>   38        x += arg;^M
>   (gdb) FAIL: gdb.c++/method.exp: continuing and breaking in A::foo
> 
> So you can see that 'break A::foo' works and gdb takes the breakpoint.
> I don't know what that "FAIL" is about (that is a different issue).

Probably the fact that the name of the function is 'A::foo(int)'.  I
fixed this in the testsuite on the trunk (or Jason did; I don't
recall).

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

Re: GDB C++ support

[Michael Elizabeth Chastain]

gdb 5.0 was released on 2000-05-19
gcc 3.0 was released on 2001-06-20
gdb 5.1 was released on 2001-11-22

That's why the gcc 3 support in gdb 5.0 isn't very good!

So try gdb 5.1.  It works much better with gcc 3 versions.

(And gdb 5.2, whenever it comes out, will be much better than gdb 5.1.)

Michael Elizabeth Chastain
<mec@shout.net>
"love without fear"

Re: GDB C++ support

[Eli Zaretskii]

On Mon, 14 Jan 2002, Michael Elizabeth Chastain wrote:

> So try gdb 5.1.  It works much better with gcc 3 versions.

Do you (or someone else) happen to know whether v5.1 solves some or
all of the specific problems Guido described in his message?  If not,
he has no reason to try GDB 5.1, does he?

I've seen too many messages here which describe problems GDB 5.1 has
debugging C++ code, and I know too little about these problems to tell
whether they are relevant to Guido's case.  That's why I suggested him
to write here, hoping that someone could provide a more specific
answer.

GDB C++ support

[Guido S.]

Hi,

I talked to Eli Zeretzki about this recently, and he suggested to post this
on this list:

given the following source:

<code>
class A
{
 public:
...
 void f( ostream & o);
};

main()
{
    A my_A;
    my_A.f(cerr);
}
</code>

i enter gdb and want to use b 'A::f', which doesn't work (just no symbol
info in demangled form for gdb available)

b 'main()' works ... strange enough. so classless names (which I assume are
not mangled/encoded in c style) are possible.
when I set the breakpoint via b gdbtest.cpp:24 it stops and shows the
appropriate line as:

Breakpoint 1, main () at gdbtest.cpp:31
31              A       m(5);
(gdb) c
Continuing.

Breakpoint 2, _ZN1A1fERSo (this=0x1f13fd8, o=@0x3b4c0) at gdbtest.cpp:24
24              o << i << endl;

(gdb) info stack
#0  _ZN1A1fERSo (this=0x1f13fd8, o=@0x3b4c0) at gdbtest.cp
#1  0x1e8c in main () at gdbtest.cpp:32
#2  0x5a82 in __crt1_startup ()
    at c:/djgpp/lang/cxx-v3/bits/locale_facets.tcc:75

this is for gcc 3.0.3, gdb 5.0 and compiled with -gstabs+, using djgpp 2.03

So my question would be, how far the work on support for C++ and gcc 3.x
went as of now, and if one could expect some solution to this problem in the
near future?

It just confuses me, that the development of gcc and gdb seems so
asynchronous, and a compiler suite, as elegant as it may be, withers away if
it lacks usable debugging support.

But I may be mistaken, and am just not able to find out the right -g<format>
specifier to achieve full symbolic debugging. In that case I'ld be thankful
for any guidance.

But I am thankful anyway for the mere existence of gcc and gdb nonetheless
:) and the works of all the ones involved.

Cheers,
Guido