From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26943 invoked by alias); 21 Jul 2008 17:11:28 -0000 Received: (qmail 26933 invoked by uid 22791); 21 Jul 2008 17:11:27 -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; Mon, 21 Jul 2008 17:11:10 +0000 Received: (qmail 15576 invoked from network); 21 Jul 2008 17:11:08 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 21 Jul 2008 17:11:08 -0000 Message-ID: <4884C325.4060906@codesourcery.com> Date: Mon, 21 Jul 2008 17:39:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Pedro Alves CC: gdb@sourceware.org, Stan Shebs , Mark Kettenis Subject: Re: Towards multiprocess GDB References: <4880FFA8.3080600@earthlink.net> <200807182141.m6ILfBcf014252@brahms.sibelius.xs4all.nl> <488118EE.90508@codesourcery.com> <200807190013.24604.pedro@codesourcery.com> In-Reply-To: <200807190013.24604.pedro@codesourcery.com> 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/msg00239.txt.bz2 Pedro Alves wrote: > A Friday 18 July 2008 23:27:58, Stan Shebs wrote: > > >> 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. >> > > You seem to be thinking of the symbol handling code only. > > The thing I see requiring architecting, is the target stack. > You make very good points about the target stack. As I understand it, the immediate project is merely to support multiple programs all using the same target, so I've been concentrating on the symbol side. But you're right, I think we do want the target objects to be per-program. This connects to another longstanding wishlist item, which is to change target stacking to be more procedural, and less literally stacklike. With multiple programs, and inferiors scattered around the net, the target "stack" starts looking more forest-like, and it seems like it might be simpler to construct target objects as compositions of target descriptions, with the stack being more like the composition procedure than a literal stack. Thinking about it from the user point of view, I wonder if we need to merge the "target", "run", and "attach" commands into some kind of super-command that amounts to "get all the inferiors ready to debug", so that the old commands are all special cases. Stan