This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: =frame-selected MI notification


Tom Tromey wrote:

>>>>>> "Dmitry" == Dmitry Dzhus <dima@sphinx.net.ru> writes:
> 
> Dmitry> Nick Roberts once posted a patch which implements both =thread-selected
> Dmitry> and =frame-selected via observers:
> Dmitry> http://sourceware.org/ml/gdb-patches/2008-04/msg00377.html.
> 
> I didn't see any discussion of this patch in the archives.
> Was it just forgotten?
> 
> In general I think that it makes sense to have MI notifications for
> state changes caused by CLI commands.
> 
> Dmitry> Current implementation of =thread-selected in mi-main.c uses a
> Dmitry> different approach, comparing current thread ID before and after
> Dmitry> executing a command in `mi_execute_command` function. My patch
> Dmitry> does the same for frame level. I don't know how is it
> Dmitry> technically better. I think it would be nice if somebody
> Dmitry> reviewed Nick's patch once again or at least accepted the one
> Dmitry> proposed by me.
> 
> I tend to prefer Nick's approach.  I like the use of observers.

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. The design I am pushing for is that
frontend maintains the current thread and frame (possibly, different for different
main window, even) and uses --thread and --frame options to MI commands to
obtain necessary information in the context of the desired thread.

The only thing frontend might want to know from GDB is that a CLI command
has explicitly asked to change thread or frame -- in which case frontend
might want to switch its own current thread or frame. To reiterate,
frontend does not care about thread or frame switches that GDB might
do internally. 

It was decided that the easiest way to detect such explicit request
from the user is to note that thread has changed after an MI command
was executed. It seems reasonable to apply the same logic to frame.

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.

- Volodya



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]