From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9615 invoked by alias); 29 May 2008 19:48:31 -0000 Received: (qmail 9606 invoked by uid 22791); 29 May 2008 19:48:31 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 29 May 2008 19:48:13 +0000 Received: (qmail 22371 invoked from network); 29 May 2008 19:48:12 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 29 May 2008 19:48:12 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: multi-process remote protocol extensions Date: Fri, 30 May 2008 13:35:00 -0000 User-Agent: KMail/1.9.9 Cc: Michael Snyder References: <200805272233.24078.pedro@codesourcery.com> <1212083885.3601.179.camel@localhost.localdomain> In-Reply-To: <1212083885.3601.179.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805292048.10908.pedro@codesourcery.com> 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-05/txt/msg00176.txt.bz2 A Thursday 29 May 2008 18:58:05, Michael Snyder wrote: > Hi Pedro, > > I'd like to throw out some thoughts *before* I read your > somewhat long but apparently well-thought-out proposal. > I'll be brief. > > Forgive me if what I toss out has already been covered. > > Have you considered the cross-over between the general > case of debugging multiple processes, and the more restricted > case of debugging forks of the same process? With forks, > (and excluding exec for the moment), you actually have > several processes with separate address spaces but one > common symbol table. > Yes, we have. In fact, we've been using native forks as prototype for non-stop, multi-process support. The main difference to the current fork support, is that we enable all processes to be running concurrently, while the current support always leaves the non-current processes stopped. > I'm thinking that the support for fork debugging that we > already have might serve as a stepping-off point for what > you propose. > > Maybe an incremental step would be to extend the fork > debugging functionality into the remote protocol and > get it to work with gdbserver? > That has been considered. > I'll just go off and actually read what you wrote now... > ;-) Thank you very much! -- Pedro Alves