Re: MI non-stop mode spec

[Pawel Piech <pawel.piech@windriver.com>]

FYI, I'm still waiting for approvals to GPL our debugger's MI protocol 
extensions.  I will let you know as soon as I have an answer.
-Pawel

Pawel Piech wrote:
> Hi Daniel,
> I will check with my management to see if we can share our protocol 
> specification.  I don't think there will be any blocking issues but we 
> may need to include an open source license on it.  I'll get back to 
> you with this in a couple of days.
>
> Cheers,
> Pawel
>
> Daniel Jacobowitz wrote:
>> On Fri, Mar 21, 2008 at 11:12:34AM -0700, Pawel Piech wrote:
>>  
>>> The Wind River debugger which implements the MI protocol, supprots  
>>> multi-core/multi-process debugging, non-stop and all-stop debugging 
>>> modes simultaneously (for different targets), uses the above 
>>> protocol  extensions for several years now rather successfully.  So 
>>> I hope you  consider these suggestions seriously even if they are 
>>> not easiest to  implement given the GDB architecture.
>>>     
>>
>> Hi Pawel,
>>
>> Is there any documentation for Wind River's MI protocol which you
>> could share with us as a basis?  Either with the list, or privately
>> with CodeSourcery - we have some NDAs in place with Wind River, if
>> that's needed.  Obviously you have some implementation experience
>> that we'd love to benefit from here.
>>
>> Multi-core, multi-process, and multi-thread debugging are all
>> different but they're very tightly related so thinking about them
>> all at once may be best.  GDB's only current support for multi-core
>> models each core as a thread; in some cases that's exactly right,
>> in some it isn't.
>>
>> Though perhaps we should break that out into a separate conversation.
>> The current threading model is enough to make hopefully solid progress
>> on non-stop for a single multi-threaded program.
>>
>> I think the most attractive option I've seen so far is to make
>> automatic context switching optional.  We could disable it by default
>> when non-stop debugging is enabled.  Or a smarter version:
>> automatically switch contexts when we stop if previously selected
>> thread was running.  So if all threads are running and one thread gets
>> an event, we will automatically switch to that thread; but if two
>> threads stop in quick succession we'll leave the first one selected.
>> That might be overly confusing for MI clients; I'm thinking about
>> a hypothetical CLI version here.
>>
>>   
>