From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25326 invoked by alias); 21 Jul 2008 18:21:51 -0000 Received: (qmail 25314 invoked by uid 22791); 21 Jul 2008 18:21:51 -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; Mon, 21 Jul 2008 18:21:33 +0000 Received: (qmail 24145 invoked from network); 21 Jul 2008 18:21:32 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 21 Jul 2008 18:21:32 -0000 Message-ID: <4884D3A6.2020209@codesourcery.com> Date: Mon, 21 Jul 2008 18:32:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Michael Snyder CC: gdb@sourceware.org Subject: Re: Towards multiprocess GDB References: <4880FFA8.3080600@earthlink.net> <1216599968.3549.478.camel@localhost.localdomain> In-Reply-To: <1216599968.3549.478.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-07/txt/msg00242.txt.bz2 Michael Snyder wrote: > Yarg. I can imagine wanting to debug several core files at once > (failure of a multi-process application, maybe), but mixed core > files and live processes? I think maybe we should disallow that... > What would happen when you said "continue"? > In practice, I think there are going to be nonsensical combinations, but we can just exclude them as they come up. For a first version it seems reasonable to only work if all the arguments use the same target, and then allow more variation once Pedro implements the multi-target capability he described. :-) If targets are per-program, then "all continue" could be quite a circus - no effect on cores, ptrace calls to local inferiors, and a spray of packets to remote targets, which are fortunately async, so they don't mind getting an extra continue packet or two. :-) > How about this as a first increment? Could we extend > what we now have with forks, so that GDB could individually > control the separate process ids (including threads, if they > have them), while forestalling dealing with separate symbol > files because forks can all share the same one? > I want to jump on symbol files quickly, because I think it may be the long pole - I hope not, but we don't know for sure yet, lots of old code with old assumptions. Our clientele is mainly interested in embedded (more protocol and gdbserver hackery, whee), so native fork support seems most likely as either testing support or a volunteer contribution. Stan