Re: RFC: MI output during program execution

[Daniel Jacobowitz <drow@false.org>]

On Mon, Aug 15, 2005 at 10:54:44AM +1200, Nick Roberts wrote:
> 
> I've read most of the discussion through the archives.  I find the idea of
> notifying the frontend about all changes of state a laudable goal but
> currently too difficult (for me).  However, I would still like GDB to
> convey to the frontend when the inferior is running.  Jim's point about the
> "define" command shoots down the patch that I sent earlier so I would like to
> suggest another approach.  I would like to take the "^running" and "*stopped"
> tokens out of mi-main.c and put them in infrun.c where annotate_starting and
> annotate_stopped are respectively called.  This seems more in line with the
> idea of notification and works when I test it natively on GNU/Linux.  I am
> sure that it will fail somewhere else (remote targets?) otherwise this
> approach would have surely been used in the first place.
> 
> With this method user-defined commands work as for simple GDB commands.  CLI
> commands don't give full MI output but information like the current line can
> be obtained by polling with -stack-info-frame.
> 
> -exec-next
> ^running
> (gdb) 
> *stopped,reason="end-stepping-range",thread-id="0",frame={addr="0x080484ef",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffff794"}],file="myprog.c",fullname="/home/nick/myprog.c",line="46"}
> (gdb) 
> n
> &"n\n"
> ^running
> (gdb) 
> ~"47\t  int n1=7, n2=8, n3=9;\n"
> *stopped
> ^done
> (gdb) 
> 
> Using strcmp (interpreter_p, "mi") and not strncmp (interpreter_p, "mi", 2)
> means that this should only change behaviour for the current mi level.

Checking the name of the MI interpreter seems inelegant.  It'll break
this when we transition from MI2 to MI3 as the stable version for
instance.  Maybe there's a way to make mi_version usable outside of
mi/*.

Forcing this to raw_stdout is also not OK, since my whole point was to
pass this information to the interpreter so that it can distribute it
to clients appropriately - they may not be on stdout.  I realize that's
what the MI layer previously did, but I don't get a good taste in my
mouth from bypassing the MI output layer this way.

The hooks we were talking about were primarily for things like the
breakpoint list and thread list.  The ^running response is touchier.
^running is a result record, not an async record.  It has to be the
result of a command.  Bob's our expert on this, but I'd think that this
change could break the grammar.  There's probably a way to get this to
happen when the resulting prompt does not signify that another command
may be accepted now.

Certainly it makes verifying from the source that we obey the grammar
much more difficult, by moving bits of the MI implementation into
infrun.  That's enough reason for it not to have been done this way in
the first place - it's harder to maintain.

Also, Bob said he was willing to work on doing this correctly.

-- 
Daniel Jacobowitz
CodeSourcery, LLC