From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30393 invoked by alias); 21 Jul 2008 16:38:43 -0000 Received: (qmail 30384 invoked by uid 22791); 21 Jul 2008 16:38:42 -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 16:38:25 +0000 Received: (qmail 10785 invoked from network); 21 Jul 2008 16:38:24 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 21 Jul 2008 16:38:24 -0000 Message-ID: <4884BB79.60707@codesourcery.com> Date: Mon, 21 Jul 2008 17:11:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: tromey@redhat.com CC: gdb@sourceware.org Subject: Re: Towards multiprocess GDB References: <4880FFA8.3080600@earthlink.net> In-Reply-To: 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/msg00238.txt.bz2 Tom Tromey wrote: > This is particularly interesting if you are watching a very large tree > of processes. It would be nice if gdb did not have eagerly to read > symbols for every program. > Yes, that would be good. I think that if things like breakpoint locations include an exec name, then inferior control need do nothing more than catch the fork/exec, and let the programs with nonmatching names continue on without further ado. > Another idea, related to something in HPD, would be to come up with a > general syntax for naming things -- like "#PID#file.c:function" (or > what have you) -- so the user can easily embed a context into a name. > (I dunno if this is useful, I'm just brainstorming a bit.) > We're going to want some sort of syntax, don't want to commit to any particular character(s) yet. :-) > Stan> Conversely, the user will also want a way to take programs out > Stan> of the debugging session. This is not quite the same as > Stan> detaching, because the user may want, say, the server to > Stan> continue doing its serving thing > > I don't understand the distinction here. With 'detach' the server > would continue serving... what am I missing? > I'm thinking one may want to flush symbol tables, so as to reduce ambiguity. Otherwise you could end up with more and more versions of main() over time, and very long selection menus in response to "break main", but with many or most of the entries being for programs not actually being debugged at the moment. > Stan> Although my inclination is to create a new symbol table for each > Stan> process' image of each shared library, that may be excessively > Stan> expensive. > > To me this sounds important to solve, though of course I have no > numbers. I am just thinking that every program is going to be mapping > in libc, and it would be great to scale to a large number of inferiors. > FWIW the particular scenario I am interested in is running "make check" > in the gcc tree, under gdb, and having it stop only when some > sub-process gets a SEGV. So, the question is, how does gdb react to > thousands of process creations and deletions, how eagerly does it read > and discard symbol table info, etc. > That's a really great scenario to keep in mind, and totally doable I think, though maybe not on the first iteration. :-) Stan