From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25060 invoked by alias); 18 Jul 2008 21:21:23 -0000 Received: (qmail 25038 invoked by uid 22791); 18 Jul 2008 21:21:22 -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 21:20:47 +0000 Received: (qmail 7215 invoked from network); 18 Jul 2008 21:20:45 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Jul 2008 21:20:45 -0000 Message-ID: <48810927.3020004@codesourcery.com> Date: Fri, 18 Jul 2008 21:41:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Paul Koning CC: gdb@sourceware.org Subject: Re: Towards multiprocess GDB References: <4880FFA8.3080600@earthlink.net> <18561.528.278824.732595@gargle.gargle.HOWL> In-Reply-To: <18561.528.278824.732595@gargle.gargle.HOWL> 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/msg00213.txt.bz2 Paul Koning wrote: >>>>>> "Stan" == Stan Shebs writes: >>>>>> > > Stan> When it's time to run, the user will want the ability to run > Stan> anywhere from one to all of the programs, each with its own > Stan> argument list. It should be possible to do this with a single > Stan> command, so that the user isn't scrambling to put in all the > Stan> run commands quickly enough. > > Nice. > > Do we need a way to specify a different environment for each program? > Yep, "path" and "set environment" and friends will all need per-program controls. > Stan> Implementationwise, we will need to replace the single exec > Stan> target with a list of execs, and modify symbol machinery to > Stan> support a many-many relationship between programs and symbol > Stan> tables. Although my inclination is to create a new symbol table > Stan> for each process' image of each shared library, that may be > Stan> excessively expensive. > > Indeed it might be excessive. Avoiding it means adding the notion of > per-program offsets, so program A can map library L at offset X, while > program B maps that same library at offset Y. > Yeah, I'm not yet sure whether we can do it without having to modify all the symbol lookup sites. It might make sense to have new symbol table objects that consist of process, offsets, and link to old-style symbol tables. > Stan> In addition to thoughts on desired user interface, I would > Stan> welcome suggestions on how to add this feature incrementally; > Stan> the abovementioned bits are a lot to add all at once! > > You mentioned threads in passing. Those are still needed, so you need > to allow multiple programs each of which may have multiple threads. > That's right. In a way execution control is in better shape for this than other areas, because it's already had some hacking to facilitate listening to multiple issuers of events and such. Stan