gdba problems with C++ code

gdba problems with C++ code

[Werner LEMBERG]

[Emacs CVS 2006-07-30]

I tried to debug troff, which is written in C++.

Starting gdba, I just added `troff' as the only argument (in addition
to -annotate=3).  Setting a breakpoint on `process_input_stack', I
started the program.  Hitting the breakpoint, the *locals of troff*
window shows, among other things,

  trap_bol_stack = [struct/union]

Creating a watch expression shows me

  +trap_bol_stack	int_stack

(where the `+' sign stands for the small icon) in a separate speedbar
frame, as expected.  But clicking on that with mouse-2 gives nothing.

In the *gud-troff* buffer I can do the following:

  (gdb) p trap_bol_stack
  $1 = {top = 0xbfe6bc68}

thus I've expected that clicking on the watch expression opens a tree,
showing me the value of `top'.

The same happens for more complex structures too: It isn't possible
for me to get a tree of the variables within the structure.  This
makes gdba completely useless for me.

Am I doing something wrong?  Isn't C++ supported?  I use gdb 6.3 in
case it matters.


    Werner

Re: gdba problems with C++ code

[Nick Roberts]

Werner LEMBERG writes:
 > 
 > [Emacs CVS 2006-07-30]
 > 
 > I tried to debug troff, which is written in C++.
 > 
 > Starting gdba, I just added `troff' as the only argument (in addition
 > to -annotate=3).  Setting a breakpoint on `process_input_stack', I
 > started the program.  Hitting the breakpoint, the *locals of troff*
 > window shows, among other things,
 > 
 >   trap_bol_stack = [struct/union]
 > 
 > Creating a watch expression shows me
 > 
 >   +trap_bol_stack	int_stack
 >
 > (where the `+' sign stands for the small icon) in a separate speedbar
 > frame, as expected.  But clicking on that with mouse-2 gives nothing.

If int_stack is just a structure or union it should work.
Or is it a data type that is special to C++?

 > In the *gud-troff* buffer I can do the following:
 > 
 >   (gdb) p trap_bol_stack
 >   $1 = {top = 0xbfe6bc68}
 > 
 > thus I've expected that clicking on the watch expression opens a tree,
 > showing me the value of `top'.

If it has only one element it should look something like:

   [-] trap_bol_stack	int_stack
    [+] top             top_type

depending on the data type of top.

 > The same happens for more complex structures too: It isn't possible
 > for me to get a tree of the variables within the structure.

What operating system are you using?  What is the exact version of GDB are you
using? e.g on FC5 I get:

  GNU gdb Red Hat Linux (6.3.0.0-1.122rh)


 >                                                             This
 > makes gdba completely useless for me.

That may be so if all you do when debugging is watch the values of complex data
types.  Most other people do many other things.

 > Am I doing something wrong?  Isn't C++ supported?  I use gdb 6.3 in
 > case it matters.

As it says in the manual (it would be a good idea to read it, if you haven't)
and the file header for gdb-ui.el, watch expressions work best with GDB 6.4
onwards.  With 6.3 and more complex structures it may be just that you're not
waiting long enough.  Current GDB is 6.5, it might help to update to that.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: gdba problems with C++ code

[Werner LEMBERG]

>  > Creating a watch expression shows me
>  >
>  >   +trap_bol_stack	int_stack
>  >
>  > (where the `+' sign stands for the small icon) in a separate speedbar
>  > frame, as expected.  But clicking on that with mouse-2 gives nothing.
>
> If int_stack is just a structure or union it should work.
> Or is it a data type that is special to C++?

It's a class, with a single variable and some functions.

> If it has only one element it should look something like:
>
>    [-] trap_bol_stack	int_stack
>     [+] top             top_type
>
> depending on the data type of top.

This doesn't happen.  Clicking on [+] left of `trap_bol_stack' does nothing.

> What operating system are you using?  What is the exact version of GDB are you
> using? e.g on FC5 I get:
>
>   GNU gdb Red Hat Linux (6.3.0.0-1.122rh)

I told you the exact version.  It's plain 6.3.

>  > This makes gdba completely useless for me.
>
> That may be so if all you do when debugging is watch the values of
> complex data types.  Most other people do many other things.

Well, there aren't any line breaks in the output of, say, `p
trap_bol_stack' if typed in manually due to the -annotate argument!
Getting an overview of a class is thus really difficult.

> As it says in the manual (it would be a good idea to read it, if you
> haven't) and the file header for gdb-ui.el, watch expressions work
> best with GDB 6.4 onwards.

Hmm, the manual doesn't say that explicitly.  It just talks about some
features available in version 6.4 and later.  Perhaps this can be
emphasized.

> With 6.3 and more complex structures it may be just that you're not
> waiting long enough.  Current GDB is 6.5, it might help to update to that.

Meanwhile I've done that (compiling the 6.5 tarball by myself), and it
changes nothing.  Neither structures nor classes get displayed.


    Werner

Re: gdba problems with C++ code

[Eli Zaretskii]

> Date: Tue, 05 Sep 2006 00:36:33 +0200 (CEST)
> From: Werner LEMBERG <wl@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> Meanwhile I've done that (compiling the 6.5 tarball by myself), and it
> changes nothing.  Neither structures nor classes get displayed.

Can you do the same with stand-alone GDB using the CLI interface?

(I'm unsure whether the problems you describe are in GDB or in Emacs,
or some mixture thereof.)

Re: gdba problems with C++ code

[Nick Roberts]

 > > If int_stack is just a structure or union it should work.
 > > Or is it a data type that is special to C++?
 > 
 > It's a class, with a single variable and some functions.

Ah! I see.  I can reproduce this (there must have been a regression because
it used to work for classes).

I have installed a fix.  Please tell me if it works for you.

 > > What operating system are you using?  What is the exact version of GDB are you
 > > using? e.g on FC5 I get:
 > >
 > >   GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
 > 
 > I told you the exact version.  It's plain 6.3.

There is no such thing as plain 6.3.  Different code is used to build GDB
for different OSes.

 > Meanwhile I've done that (compiling the 6.5 tarball by myself), and it
 > changes nothing.  Neither structures nor classes get displayed.

It should prove a worthwhile exercise now as it should be a lot quicker at
displaying watch expressions than 6.3.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: gdba problems with C++ code

[Werner LEMBERG]

>  > It's a class, with a single variable and some functions.
> 
> Ah! I see.  I can reproduce this (there must have been a regression
> because it used to work for classes).
> 
> I have installed a fix.  Please tell me if it works for you.

It works.  Thanks for quick fix.


    Werner

Re: gdba problems with C++ code

[Werner LEMBERG]

> I think I've installed a fix.  Please tell me if it works for you
> again.

It does, thanks.  For the moment, I have only one remaining question
which is probably not directly related to gdba: Using mouse-1 to open
the tree leaves (for structures watched in the speedbar frame)
sometimes fails.  I have to click just once to open it, right?  For
me, this often doesn't work, and I have to click again on the icon to
see a reaction.  Have you ever seen such a problem?  It looks like
Emacs doesn't receive all mouse events, or that they get lost
somewhere.  I use the CVS from today on a GNU/Linux box, running X
6.9.0.


    Werner

Re: gdba problems with C++ code

[Nick Roberts]

 > It does, thanks.  For the moment, I have only one remaining question
 > which is probably not directly related to gdba: Using mouse-1 to open
 > the tree leaves (for structures watched in the speedbar frame)
 > sometimes fails.  I have to click just once to open it, right?  For
 > me, this often doesn't work, and I have to click again on the icon to
 > see a reaction.  Have you ever seen such a problem?  It looks like
 > Emacs doesn't receive all mouse events, or that they get lost
 > somewhere.  I use the CVS from today on a GNU/Linux box, running X
 > 6.9.0.

I don't think it's an Emacs problem.  It doesn't happen if you are just
browsing files in the speedbar, right?  I think it's because I've made
gdb-enqueue-input a no-op if GDB is still executing (gud-running is t) :

 (defun gdb-enqueue-input (item)
   (if (not gud-running)
       ^^^^^^^^^^^^^^^^
       (if gdb-prompting
 	   (progn
	     (gdb-send-item item)
	     (setq gdb-prompting nil))
	 (push item gdb-input-queue))))

You can get better response if you omit that clause but Emacs might get
confused at times.  GDB/MI should make things easier with tokens to
tie GDB output to GDB input.


-- 
Nick                                           http://www.inet.net.nz/~nickrob