Re: GSoC gdb-mi.el changes

[Dan Nicolaescu <dann@ics.uci.edu>]

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?