Re: RFC: MI output during program execution

[Nick Roberts <nickrob@snap.net.nz>]

 > What I offered to work on (because you mentioned you didn't have time),
 > is to improve the MI interface, by changing GDB's internals to alert
 > other parts of GDB (MI, maybe annotate=2,3) when certain conditions or
 > states have changed. For instance, breakpoints, frame's, threads, or
 > inferior state.

I wasn't just a question of time, I don't currently have enough understanding
of the code as a whole.  I do know that there will be problems with threads,
for example.  Previous discussion on the mailing list has shown that GDB loses
track of the selected frame when the thread is changed back and forth.  Also
variable objects don't record the thread for which they were created.

 > By doing this, the MI layer can then check to see what has changed after
 > each command is run, including -interpreter-exec console commands. The
 > MI layer can then issue data to the FE depending on what has changed,
 > and potentially what the FE requested for changes.
 > 
 > This might require changing the MI output syntax to add a new section
 > for changes like above. I'm not sure about this yet.
 > 
 > Does this proposed solution sound reasonable to you? Will this solve all
 > the needs that you have? To be honest, CGDB also won't work without
 > these changes. However, with theses changes, MI might be getting close
 > to being very usable, thus, deprecating annotations. Do you agree?

I poll GDB to get the state after every command.  This might be slower but
it's generally workable.  On the other hand, I can't find out if the inferior
is running or not when a CLI command is executed.  I don't think that your
proposed changes will solve this problem.

 > To be realist, I expect these changes to take several months. Especially
 > since Mark Kettenis asked that all the deprecated functions be removed
 > first. Hopefully the time won't be an issue.

More like several years I would think!  The location of the deprecated
functions in the code tells you where notification should take place.  I would
remove these once you have your code working.  This presumably also provides a
fallback position.

Nick