From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13827 invoked by alias); 18 Jul 2008 22:28:27 -0000 Received: (qmail 13819 invoked by uid 22791); 18 Jul 2008 22:28:26 -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; Fri, 18 Jul 2008 22:28:06 +0000 Received: (qmail 14772 invoked from network); 18 Jul 2008 22:28:04 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Jul 2008 22:28:04 -0000 Message-ID: <488118EE.90508@codesourcery.com> Date: Fri, 18 Jul 2008 23:09:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Mark Kettenis CC: gdb@sourceware.org Subject: Re: Towards multiprocess GDB References: <4880FFA8.3080600@earthlink.net> <200807182141.m6ILfBcf014252@brahms.sibelius.xs4all.nl> In-Reply-To: <200807182141.m6ILfBcf014252@brahms.sibelius.xs4all.nl> 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/msg00217.txt.bz2 Mark Kettenis wrote: >> Date: Fri, 18 Jul 2008 13:40:08 -0700 >> From: Stan Shebs >> >> CodeSourcery has a project to add "multiprocess" capability to GDB, >> and with this message I'd like to kick off some discussion of what >> that means and how to make it happen. >> > > Please remind me, why was this a desirable capability again? > I thought everybody knew that from when I wrote it into the original GDB 5 wishlist back in 1995 or so. :-) > Personally, I can't imagine someone would really want to do this using > the traditional gdb CLI, at least not within a single gdb instance. > I'd simply fire up two (or more) xterms and debug the processes > seperately. One thing that could be useful though for that scenario > is the ability to hand of processes between gdb instances upon > fork/exec. > You hit on one of the reasons right there. Even the two-xterm case starts to involve some juggling, where you're trying to get to the other xterm and continue or whatever, before the first program times out. (At least I always seem to fumble the mouse clicking at that key point.) And if you've set the first program not to time out, then maybe you've changed its behavior in such a way as to suppress the bug. So the single GDB instance gives you tighter control over the several programs. I think there also advantages in terms of sharing history, symbols, and so forth; "break foo" can be a very interesting way to discover which program's foo() gets hits first, for foo() in a shared library. > Adding a "multiprocess" capability to GDB is almost certainly going to > add significant complexity. So there should be a good motivation for > it. > I'm not sure it's going to be that big of a change actually. Once behavior has been directed to the right objects internally, they will do what they're doing now. Most symbol handling is objfile-relative for instance, adding a new set of objfiles for a different exec isn't going to affect that code. Stan