From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3002 invoked by alias); 21 Jul 2008 16:08:17 -0000 Received: (qmail 2858 invoked by uid 22791); 21 Jul 2008 16:08:16 -0000 X-Spam-Check-By: sourceware.org Received: from shell4.BAYAREA.NET (HELO shell4.bayarea.net) (209.128.82.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 21 Jul 2008 16:07:56 +0000 Received: (qmail 32205 invoked from network); 21 Jul 2008 09:07:04 -0700 Received: from 209-128-106-254.bayarea.net (HELO redwood.eagercon.com) (209.128.106.254) by shell4.bayarea.net with SMTP; 21 Jul 2008 09:06:56 -0700 Message-ID: <4884B40C.3010707@eagercon.com> Date: Mon, 21 Jul 2008 16:38:00 -0000 From: Michael Eager User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Stan Shebs CC: gdb@sourceware.org Subject: Re: Towards multiprocess GDB References: <4880FFA8.3080600@earthlink.net> In-Reply-To: <4880FFA8.3080600@earthlink.net> Content-Type: text/plain; charset=UTF-8; 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/msg00237.txt.bz2 Stan Shebs wrote: > 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. > > To put it simply, the goal of the project is to make this command work > in some useful way: > > gdb prog1 prog2 pid2 prog3 prog4 > > As the command suggests, we're talking about multiple programs or > executables being controlled by a single GDB, in contrast to a single > program with multiple processes or forks, a la Michael's machinery for > Linux forks. So although we often use the term "multiprocess", it's > perhaps more precise to call it "multiprogram" or "multiexec" GDB. I think that this is a subset of what is actually needed. A good starting point, but it doesn't address present and future architectures. I would like to see GDB become a multi-process, multi-target, multi- architecture debugger. There are many multi-processor systems, where several processing units make up the target. One example is the Cell: a PowerPC processor connected to multiple special-purpose processors. There are many RISC-DSP processors; there are efforts to re-purpose Nvidia's massively parallel GPUs to more conventional programming; and the future of processor design is multicore, not all of will be the same architecture or connected symmetrically. An SMP architecture running a single Linux OS is a subset. The target abstraction to support this needs to permit multiple threads on multiple targets, with different architectures, different executables, and different communication protocols. Clearly, if this were the target abstraction, supporting multiple processes running on the same processor under a single OS would be easy. A design which only focuses on this subset will not be easy to extend to multiple dissimilar execution environments. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077