From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3587 invoked by alias); 18 Jul 2008 22:13:59 -0000 Received: (qmail 3578 invoked by uid 22791); 18 Jul 2008 22:13:58 -0000 X-Spam-Check-By: sourceware.org Received: from smtp1.dnsmadeeasy.com (HELO smtp1.dnsmadeeasy.com) (205.234.170.134) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 18 Jul 2008 22:13:36 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id DF3D131F644; Fri, 18 Jul 2008 22:13:49 +0000 (UTC) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Fri, 18 Jul 2008 22:13:49 +0000 (UTC) Received: from dl2.hq2.avtrex.com ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Jul 2008 15:13:32 -0700 Message-ID: <4881158B.4010704@avtrex.com> Date: Fri, 18 Jul 2008 22:20:00 -0000 From: David Daney User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Mark Kettenis Cc: stanshebs@earthlink.net, 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 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-07/txt/msg00215.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? > > 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. > > I suppose multiprocess debugging makes somewhat more sense in a > GUI-based IDE environment. But running multiple instances of gdb > should work just as well in that case. > > Adding a "multiprocess" capability to GDB is almost certainly going to > add significant complexity. So there should be a good motivation for > it. Here's my take on it (not being at all involved in the effort): Suppose that you are debugging both a client and a server process. One scenario is that you want to debug the results of some command sent between them. Set a break point in the command handler and disable it. In the other process set a breakpoint just before sending the command. This breakpoint's commands could enable the break point in the other process and continue. Doing this with a multiprocess gdb would be trivial. If you have to use multiple gdb instances, it is either a manual process or some complicated scripting setup. Just my $0.02, David Daney