From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28811 invoked by alias); 21 Jul 2008 17:57:46 -0000 Received: (qmail 28801 invoked by uid 22791); 21 Jul 2008 17:57:45 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 21 Jul 2008 17:57:28 +0000 Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id m6LHvLVB030634 for ; Mon, 21 Jul 2008 18:57:21 +0100 Received: from yx-out-2324.google.com (yxg8.prod.google.com [10.190.2.136]) by zps78.corp.google.com with ESMTP id m6LHvHK8013436 for ; Mon, 21 Jul 2008 10:57:20 -0700 Received: by yx-out-2324.google.com with SMTP id 8so339725yxg.39 for ; Mon, 21 Jul 2008 10:57:20 -0700 (PDT) Received: by 10.151.143.14 with SMTP id v14mr4177473ybn.69.1216663040110; Mon, 21 Jul 2008 10:57:20 -0700 (PDT) Received: by 10.151.107.3 with HTTP; Mon, 21 Jul 2008 10:57:20 -0700 (PDT) Message-ID: <8ac60eac0807211057w11e9174aqc50f7f20531b127@mail.gmail.com> Date: Mon, 21 Jul 2008 18:21:00 -0000 From: "Paul Pluzhnikov" To: "Michael Snyder" Subject: Re: Towards multiprocess GDB Cc: "Stan Shebs" , gdb@sourceware.org In-Reply-To: <1216599968.3549.478.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4880FFA8.3080600@earthlink.net> <1216599968.3549.478.camel@localhost.localdomain> 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/msg00241.txt.bz2 On Sun, Jul 20, 2008 at 5:26 PM, Michael Snyder wrote: > I am a big lover of the incremental approach. > > 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 would like to add another twist (which I don't see mentioned elsewhere in this thread yet): cluster computing. Google (and I am sure many others) has great interest in being able to debug potentially 1000s of instances of execution of the same program on multiple hosts. [Naturally, each host will have at least one gdbserver running.] This is almost, but not quite the same as what Michael suggests above. -- Paul Pluzhnikov [Not officially speaking for Google.]