Re: MI non-stop interface details

[Pawel Piech <pawel.piech@windriver.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.