MI non-stop mode spec

[Pawel Piech]

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.
>
>