[PATCH:MI] Event notification
Nick Roberts
nickrob@snap.net.nz
Sun May 4 23:19:00 GMT 2008
> > 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
More information about the Gdb-patches
mailing list