From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29744 invoked by alias); 25 Mar 2008 17:46:12 -0000 Received: (qmail 29736 invoked by uid 22791); 25 Mar 2008 17:46:12 -0000 X-Spam-Check-By: sourceware.org Received: from mail.windriver.com (HELO mail.wrs.com) (147.11.1.11) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 25 Mar 2008 17:45:50 +0000 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id m2PHjmdt013164 for ; Tue, 25 Mar 2008 10:45:48 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 10:45:47 -0700 Received: from [147.11.233.101] ([147.11.233.101]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 10:45:48 -0700 Message-ID: <47E93A4A.6030504@windriver.com> Date: Tue, 25 Mar 2008 18:18:00 -0000 From: Pawel Piech User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: Re: MI non-stop mode spec References: <200803190016.02072.vladimir@codesourcery.com> <47E3FA92.40409@windriver.com> <20080324222830.GB17281@caradoc.them.org> In-Reply-To: <20080324222830.GB17281@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00220.txt.bz2 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. > >