GSoC gdb-mi.el changes

GSoC gdb-mi.el changes

[Dmitry Dzhus]

Good day gentlemen.

Recently I've installed many changes for gdb-mi.el to Emacs trunk. They
include, but not limited to, support for non-stop multithread debugging
as provided by development version of GDB 7.0 and support for observing
several threads simultaneously, as well as fixes for bugs reported in
Emacs bugs list. This work was done during my GSoC student project
(http://emacswiki.org/emacs/GDB-MI). This GDB interface fully uses GDB
Machine Interface instead of annotations used by gdb-ui.el package
present in earlier Emacs versions.

I've updated «GDB Graphical Interface» section of the Emacs manual to
reflect user-visible changes. Make sure you read the notes under
«Multithreaded Debugging» subsection before trying the new
functionality. 

I needed to add two new icons under etc/images/gud/ directory. I hope
I've updated README properly.

Suggestions and bug reports are welcome.

Please include value of `M-x pp-eval-expression RET gdb-debug-log RET'
in your bug reports. Note that this package relies on development
version of GDB 7.0, which may be unstable itself, so please include
version information about your GDB installation, too.

Thank you in advance. Looking forward to hearing your comments.

(I'm not sure if it will be appropriate to post such announcement to
Emacs users group. On one hand, some input from users would be very
helpful for me, because changes are big and bugs should come up. On the
other hand, I've never seen a package announcement on gnu.emacs.help.)
-- 
Happy Hacking.

http://sphinx.net.ru
む

Re: GSoC gdb-mi.el changes

[Chong Yidong]

Dmitry Dzhus <dima@sphinx.net.ru> writes:

> Recently I've installed many changes for gdb-mi.el to Emacs trunk. They
> include, but not limited to, support for non-stop multithread debugging
> as provided by development version of GDB 7.0 and support for observing
> several threads simultaneously, as well as fixes for bugs reported in
> Emacs bugs list. This work was done during my GSoC student project
> (http://emacswiki.org/emacs/GDB-MI). This GDB interface fully uses GDB
> Machine Interface instead of annotations used by gdb-ui.el package
> present in earlier Emacs versions.

You've been very productive.  Thanks very much for the work you've put
in.

Re: GSoC gdb-mi.el changes

[Dan Nicolaescu]

Dmitry Dzhus <dima@sphinx.net.ru> writes:

  > Good day gentlemen.
  > 
  > Recently I've installed many changes for gdb-mi.el to Emacs trunk. They
  > include, but not limited to, support for non-stop multithread debugging
  > as provided by development version of GDB 7.0 and support for observing
  > several threads simultaneously, as well as fixes for bugs reported in
  > Emacs bugs list. This work was done during my GSoC student project
  > (http://emacswiki.org/emacs/GDB-MI). This GDB interface fully uses GDB
  > Machine Interface instead of annotations used by gdb-ui.el package
  > present in earlier Emacs versions.
  > 
  > I've updated «GDB Graphical Interface» section of the Emacs manual to
  > reflect user-visible changes. Make sure you read the notes under
  > «Multithreaded Debugging» subsection before trying the new
  > functionality. 
  > 
  > I needed to add two new icons under etc/images/gud/ directory. I hope
  > I've updated README properly.

Thanks for the great effort on improving this!

  > Suggestions and bug reports are welcome.

Suggestion: don't show the -i=mi flag, users don't care about it (same
way rgrep/lgrep don't show the -n flag they pass to grep)

Issues:
echo 'int main () { printf ("Hello, World!\n");}' > t.c
gcc t.c
emacs -Q 
M-x gdb RET ./a.out RET

error in process filter: Symbol's function definition is void: mapcar*

M-x load-library RET cl RET
M-x gdb RET ./a.out RET

Show the disassembly window

b main

A warning pops up:
&"warning: GDB: Failed to set controlling terminal: Operation not permitted\n"

si 
si 
si

The cursor in the disassembly does not move correctly when single
stepping and it does not update the stack frames all the time.


GNU gdb (GDB) Fedora (6.8.50.20090302-33.fc11)


Thanks
        --dan

Re: GSoC gdb-mi.el changes

[Dmitry Dzhus]

Dan Nicolaescu wrote:

> Suggestion: don't show the -i=mi flag, users don't care about it (same
> way rgrep/lgrep don't show the -n flag they pass to grep)

I'll do this.

> Issues:
> echo 'int main () { printf ("Hello, World!\n");}' > t.c
> gcc t.c
> emacs -Q 
> M-x gdb RET ./a.out RET
>
> error in process filter: Symbol's function definition is void: mapcar*
>
> M-x load-library RET cl RET
> M-x gdb RET ./a.out RET

Uh-oh, that's very bad. Somehow I thought that mapcar* is a macro. I'll
rewrite some of my functions without mapcar* then.

>
> Show the disassembly window
>
> b main
>
> A warning pops up:
> &"warning: GDB: Failed to set controlling terminal: Operation not permitted\n"
>
> si 
> si 
> si
>
> The cursor in the disassembly does not move correctly when single
> stepping and it does not update the stack frames all the time.

(At the time of your writing, stepping was just broken; I installed some
fixes in CVS.)

Does it occur when you compile your target with -g, too?

Unlike GDB's CLI `disassemble` command, to show disassembly code for you
program, MI needs to know either file:line information for the function
you're interested in, or its memory range. For the former your target
needs to be compiled with debugging information, and for the latter we
need to query GDB for function memory range, but this command is not
implemented in GDB/MI yet :(
-- 
Happy Hacking.

http://sphinx.net.ru
む

Re: GSoC gdb-mi.el changes

[Dan Nicolaescu]

Dmitry Dzhus <dima@sphinx.net.ru> writes:

  > Dan Nicolaescu wrote:
  > 
  > > Suggestion: don't show the -i=mi flag, users don't care about it (same
  > > way rgrep/lgrep don't show the -n flag they pass to grep)
  > 
  > I'll do this.
  > 
  > > Issues:
  > > echo 'int main () { printf ("Hello, World!\n");}' > t.c
  > > gcc t.c
  > > emacs -Q 
  > > M-x gdb RET ./a.out RET
  > >
  > > error in process filter: Symbol's function definition is void: mapcar*
  > >
  > > M-x load-library RET cl RET
  > > M-x gdb RET ./a.out RET
  > 
  > Uh-oh, that's very bad. Somehow I thought that mapcar* is a macro. I'll
  > rewrite some of my functions without mapcar* then.

To see more compilation warnings, you can cd to the lisp directory and
do:
make recompile
there.  As of today you'll get some extra warnings about using
`goto-line' too.

  > >
  > > Show the disassembly window
  > >
  > > b main
  > >
  > > A warning pops up:
  > > &"warning: GDB: Failed to set controlling terminal: Operation not permitted\n"

How about this warning?

  > >
  > > si 
  > > si 
  > > si
  > >
  > > The cursor in the disassembly does not move correctly when single
  > > stepping and it does not update the stack frames all the time.
  > 
  > (At the time of your writing, stepping was just broken; I installed some
  > fixes in CVS.)

Still some problems, given the example above if in the middle of the
execution I do:
r
yes (to restart execution)

I get:
Debugger aborted
the disassembly frame disappears and the debug window does not work anymore.

  > Does it occur when you compile your target with -g, too?

It works for the code, but not when going through library functions that
don't have debug info (this worked fine in 22.1).

  > Unlike GDB's CLI `disassemble` command, to show disassembly code for you
  > program, MI needs to know either file:line information for the function
  > you're interested in, or its memory range. For the former your target
  > needs to be compiled with debugging information, and for the latter we
  > need to query GDB for function memory range, but this command is not
  > implemented in GDB/MI yet :(

Given that you know the details here, can you please file a gdb bug?
What do other GDB/MI front-ends do in this situation?

Re: GSoC gdb-mi.el changes

[Stefan Monnier]

> Suggestion: don't show the -i=mi flag, users don't care about it (same
> way rgrep/lgrep don't show the -n flag they pass to grep)

GUD used to hide such flags and then was changed to try and show
them instead.  The reason why it was changed to show them, is so that it
can be made to work with unusal ways to start the debugger.  E.g.

  make run cmd="gdb --i=mi foo"

if you don't make the flag explicit, then you have to guess where to
add it in the command the user has just typed (in the above case the
user would have then typed

  make run cmd="gdb foo"

which makes it difficult to figure out where to place the --i=mi.


        Stefan