Re: MI non-stop interface details

[Pawel Piech <pawel dot piech at windriver dot com>]

Vladimir Prus wrote:
> 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?
>   
As I mentioned before, having lots of "if (new)... else (old)..." makes 
the code hard to maintain after a while.  I think Nick got it right, 
maintaining backward compatibility is more work for the server, dealing 
with incompatibilities is more work for the client.  Right now what 
you're saying is: "what's the big deal, just do a little more work".  
Keep in mind though, there is one server, and many clients.
>   
> > > 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.
>   
This leaves out an important piece of information: the triggering 
thread, which is used by the IDE to decide which thread should get the 
focus.  You may not see a use case for it now, but sooner or later you 
will add an option to the breakpoint to stop all threads in non-stop 
mode and you'll want to tell the client which thread hit the breakpoint.

Also this behavior is incompatible with the all-stop mode (in new or old 
GDB versions).  I.e. is the all-stop mode always going to report 
thread-id="all" for every stopped and running event?  I suppose you'll 
say to just add another if-else statement...
> > > 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
>   
Can you think of a scenario in a client which would break?  Would 
KDevelop break?  Maybe implementers of other client can speak up on this. 

-Pawel

P.S. I really appreciate your effort and attention to resolve these issues.