Re: [PATCH:MI] Event notification

[Daniel Jacobowitz <drow@false.org>]

On Sun, May 04, 2008 at 03:30:56PM +0400, Vladimir Prus wrote:
> I think that when execution stops, all threads have frame 0 as selected, no?

Most of the time, but not necessarily.  For Ada we automatically
select the exception site on catch/throw events.  For C++ we do not,
but we ought to.

> 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? 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 :-)
> 
> 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.

IIRC Nick added the thread switch events only when we print out
[Switching] messages for the CLI, which are already at the sites of
explicit activity.

The other way to do it is to generate these events at prompts, either
before the result or after the prompt.  We're about to display a
prompt so we check the selected frame against what was selected last
time we displayed a prompt.  It changed?  Show an event.

-- 
Daniel Jacobowitz
CodeSourcery