Re: =frame-selected MI notification

[Vladimir Prus <vladimir@codesourcery.com>]

On Saturday 29 August 2009 Nick Roberts wrote:

>  > I'll review this patch later, but I wanted to clarify this point. The current
>  > codebase emits =thread-selected already, and it does not use observers,
>  > by design. The reason is that MI frontend is not actually interested in
>  > changes in GDB's current thread. 
> 
> I think Emacs, and other frontends that have a console, will always be
> interested in the current thread/selected frame.  The behaviour of CLI
> commands like up, down, print etc depend on it.

It seems to me that if frontend has thread 3, frame 2 presently selected
in UI, then "print" in CLI should print the value of expression in thread
3, frame 3. To that end, frontend should emit the following command:

	-interpreter-exec --thread 3 --frame 3 console "print whatever"

It does not seem like frontend need to know the value of the 'inferior_ptid' variable
in GDB source code to do that?

As I understand from talks with Dmitry on IRC, emacs already uses --thread and
--frame options as appropriate, so everything should just work. And, I also
assume that Emacs works just fine with the patch he posted.

> Of course, if GDB emits a notification then the frontend can always choose to
> ignore it.

How? GDB does not say if notification is emitted as result of internal thread
switch, or not, so frontend would need to consult an oracle to ignore notification.

> If GDB doesn't emit a notification then the frontend has to send
> an extra command to get the information it needs after after every user
> command.
> 
> It's not only thread and frame changes that could be emitted as notifications.
> Setting, deleting, disabling breakpoints with CLI commands could also emit
> notifications.  This would save having to send -break-list after every user
> command.

I think breakpoints are very different matter. Breakpoint table is an inherent
global property of debug session. You cannot sensibly have different breakpoint
tables in different IDE windows, or use different breakpoint tables for
different -exec-continue commands. Therefore, notifying a frontend about any
change to breakpoint table is uncontroversial change. We even have an
observer already -- breakpoints_changed -- that can be hooked to MI.

>  > Furthermore, I do not think that observers for either thread or frame
>  > changes is good idea, design wise. The fact that gdb has current thread
>  > or current frame at the code level, is, IMNSHO, a design bug. Global
>  > variables are generally bad, and those two are certainly not exception.
>  > It's better not to make situation worse by adding new mechanism based
>  > on that design bug.
> 
> I think it would be hard to write a large C program with no global variables
> but, in any case, the concept of current thread/selected frame seems to be a
> great convenience when using GDB from the command line.

It is convenient for command line GDB usage. This, however, does not mean that
global variable that affects all of gdb makes sense.

- Volodya