Re: [PATCH:MI] Event notification

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

 > > This patch adds event notification for changes in selected frame and
 > > thread.  In annotations, file and line information are output when the
 > > program stops and when the selected frame is changed, e.g., with "up" or
 > > "down".  Currently in MI this information is only output for the former
 > > case.  For threads, -thread-info doesn't give the selected frame and this
 > > may currently change when execution stops.
 > 
 > I think that when execution stops, all threads have frame 0 as selected, no?

All threads may have frame 0, but the frame details are different, e.g.
currently:

-thread-select 2
^done,frame={level="0",addr="0x08048968",func="myproc",args=[{name="ptr_i",value="0xbff4f73c"}],file="pthreadtest.c",fullname="/home/nickrob/C/pthreadtest.c",line="91"}
(gdb) 
-thread-select 4
^done,frame={level="0",addr="0x08048859",func="myproc",args=[{name="ptr_i",value="0xbff4f744"}],file="pthreadtest.c",fullname="/home/nickrob/C/pthreadtest.c",line="53"}
(gdb) 

 > > In any case, providing a notification it means that the frontend 
 > > doesn't need to interrogate Gdb.
 > > 
 > > A further advantage of using notifications is that they are output even
 > > when a CLI command is issued from the console.  I've discussed these ideas
 > > on the mailing list before but not used observers and in the past I've got
 > > a bit hung up on trying to detect changes in stack (too difficult).
 > > 
 > > I've not run the testsuite as I imagine it will break in many places.  I
 > > want to get this idea of decoupling MI output from the input command
 > > accepted first.  In this respect, it is somewhat similar to asynchronous
 > > output in asynchronous mode.
 > 
 > Some interesting questions arise, with the first one -- what is the exact
 > meaning of those new notifications and what is the expected reaction in
 > frontend?  For example, suppose you have a bunch of fixed variable objects
 > in different threads. Then, -var-update * will switch between threads to
 > evaluate the variable objects. This, I think, will produce a bunch of thread
 > change and frame change notifications?

It currently issues a load of frame change notifications but no thread change
ones, just because the observer isn't registered in switch_to_thread.

 >                                        What will frontend do? If a frontend
 > updates the current line indicator as result of those notifications, then
 > "-var-update *" will cause the line indicator to jump around in a fairly
 > interesting way :-)

In annotations, you can prefix a command with "server" so that it doesn't
get added to the command history.  I guess you could have a similar
convention here: a token of 0 means don't print notifications, e.g,

^0-var-update --all-values *

If we do this now, it will be backward compatible because AFAIK released Gdb
doesn't print event notifications.

 > One way to address this is to suppress those notification for implicit
 > gdb activity. I don't see how we can easily do this. Another way would
 > be instruct the frontends to ignore those notifications during some commands.
 > But then, I'm not sure how to do this without creating a huge table of
 > commands that implicitly change thread/stack, and without running the risk
 > of making the frontend act funny if we forget a command, or unintentionally
 > make some other command switch thread/frames.

-- 
Nick                                           http://www.inet.net.nz/~nickrob