Re: MI non-stop interface details

[Vladimir Prus <vladimir at codesourcery dot com>]

On Thursday 01 May 2008 22:06:03 Pawel Piech wrote:
> Vladimir Prus wrote:
> > On Wednesday 30 April 2008 21:20:24 Pawel Piech wrote:
> >   
> >> Vladimir Prus wrote:
> >>     
> >>> Again -- exec-continue resuming just one thread will be a change in behaviour.
> >>> We can take two approaches:
> >>>
> >>> 1. The MI interface we've discussed for non-stop is essentially MI3 (and will
> >>> be used both in all-stop and non-stop mode). We're in position to change anything
> >>> we like, and are not bound by backward compatibility, or anything.
> >>>
> >>> 2. The MI interface for non-stop is MI2 + minimal set of changes. I think that
> >>> Pawel's opposition to the --thread idea indicates that he prefers this approach.
> >>> Then, we rather not change the behaviour of existing commands.
> >>>
> >>> There are not many high-level warts in MI2/non-stop/async, so I'm willing
> >>> to go with (2).
> >>>
> >>> - Volodya
> >>>   
> >>>       
> >> First of all I really appreciate your effort to maintain backward 
> >> compatibility.  I know that it can seriously complicate the effort to 
> >> add new features but I believe this effort pays off in quicker and more 
> >> reliable adoption by the users (IDEs).  However, there are two kinds of 
> >> backward compatibility goals to consider:
> >> 1) Allowing old GDB clients to use the new, extended protocol.
> >> 2) Allow clients that use the extended protocol to easily work with old 
> >> protocol versions.  And by "easily", I mean that the client should be 
> >> able to not have "if(non-stop) { use command a } else { use command b}" 
> >> kind of logic scattered throughout its implementation.
> >>     
> >
> > Why do you have such a goal? 
> >   
> Adoption of new versions of GDB is gradual, so for clients support for 
> old versions of GDB is very important.

The "else" branch of your conditional handles old version of GDB, no?

> > Currently, both *running and *stopped have "thread-id" field. 
> >   
> But your proposal doesn't add any fields to the events indicating 
> whether the stopped event stops a single thread or the whole process.  

If the thread-id field has a value of "all", then all threads are stopped,
but it's just a shortcut for a number of *stopped, one per each thread.

> > I'll probably start designing multi-process extensions for MI this week,
> > and will look into these suggestions. Why are you trying to use same
> > namespace for process ids and thread ids? 
> >
> > - Volodya
> >   
> I see no reason to create a separate name space and in fact adding 
> another name space just requires more logic to maintain it.  thread-id 
> is just a handle that is obtained through well-documented commands, the 
> MI clients are not likely to get confused by the fact that containers 
> and threads are in the same namespace.  Additionally, if GDB was ever to 
> support more hierarchical systems: such as 
> target->core->processes->threads, it will have to keep revising the 
> protocol (in incompatibility inducing ways) to keep up.  But I guess 
> you'd have to believe that this is a real issue first.

I think the MI commands to query the hierarchy of "containers" will be fairly
agnostic of the actual meaning of each containers (just like variable objects
allow to describe arbitrary structure). That said, I'm not 100% that
making the namespace of containers and namespace of thread IDs is not going
to upset existing frontends.

- Volodya