Event notification in MI (was Re: fullname descriptor with -break-list)

[Nick Roberts <nickrob at snap dot net dot nz>]

Andrew Cagney writes:
 > 
 > >>-exec-run
 > >>^running
 > >>(gdb) 
 > >>*stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x080486e2",func="myprint",args=[{name="i",value="0"},{name="j",value="0"}],file="myprint.c",line="5"}

...

 > The way that message is generated is a massive kludge - so the 
 > underlying code could do with a cleanup - separate the code determining 
 > why the process stopped from the code printing the stop reason.

I think I finally understand what you were saying in an earlier thread
(Re: How does GDB/MI give the current frame - June 2004):

AC> When the user does "up", "down", the debugger should generate a selected 
AC> CLI frame changed event (it currently doesn't).  If the GUI so chooses, 
AC> it can track the users "selected" frame, by responding to these events.

I guess that this output is not associated with a particular MI command but a
change of state. In this way, the same output would be generated by a CLI
command if it produced the same change of state (I was arguing that it
shouldn't at the time), although presumably it would be only be turned on by
selecting the MI interpreter.

This complies with Richard Stallman's requirement that Emacs doesn't lose the
GUD buffer. Previously I had in mind replacing each CLI command that I used
with an MI equivalent "info break" -> -break-list, "info stack" ->
-stack-list-frames etc and updating after every user command. This is probably
less efficient and CLI commands would not always work.

Currently, "*stopped" seems to be the only such event notification implemented
in GNU GDB. Jason Molenda described a list of notifications that are
currently used by Apple's version:

JW> FWIW, here's the list of notification hooks we currently generate:  
JW> breakpoint_create, breakpoint_modify, breakpoint_delete, stack_changed,  
JW> frame_changed, thread_changed.

It would be good to have these available to GNU GDB. If Apple can merge these
changes in that would be ideal. Failing that I would like to try to implement
them in GNU GDB (using observers?). This latter approach would take much
longer, of course, and also make it harder to keep the Xcode and GNU gdb
versions in sync.


Nick