From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 673 invoked by alias); 18 Jul 2008 23:09:54 -0000 Received: (qmail 658 invoked by uid 22791); 18 Jul 2008 23:09:51 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 18 Jul 2008 23:09:33 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m6IN9HR1007991; Fri, 18 Jul 2008 19:09:17 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6IN9GpM001373; Fri, 18 Jul 2008 19:09:16 -0400 Received: from opsy.redhat.com (vpn-10-33.bos.redhat.com [10.16.10.33]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m6IN9GF9011443; Fri, 18 Jul 2008 19:09:16 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 813F05086F9; Fri, 18 Jul 2008 17:09:15 -0600 (MDT) To: Stan Shebs Cc: gdb@sourceware.org Subject: Re: Towards multiprocess GDB References: <4880FFA8.3080600@earthlink.net> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Fri, 18 Jul 2008 23:13:00 -0000 In-Reply-To: <4880FFA8.3080600@earthlink.net> (Stan Shebs's message of "Fri\, 18 Jul 2008 13\:40\:08 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00218.txt.bz2 >>>>> "Stan" == Stan Shebs writes: Stan> CodeSourcery has a project to add "multiprocess" capability to GDB, Stan> and with this message I'd like to kick off some discussion of what Stan> that means and how to make it happen. Awesome. Stan> Once the debugger is started, but before any of the programs Stan> have run, it seems obvious to have a notion of "current Stan> program", so that commands like "list main" and "break main" Stan> will work as usual. Stan> Notice that we don't really want to use the term "process" for any of Stan> this so far, because nothing is running yet and there are no Stan> processes/inferiors; this part is all about the symbol side. It is worth thinking about how things like "break main" will work after processes have been made, as well. For instance, consider something like "set follow-fork-mode both"; after a fork, where does 'break main' apply? 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. The HPD spec (which I know you worked on :) has some "focus" commands for this kind of thing. It may be worth looking at that, or looking to see what the competition (totalview cough cough) does. I suppose the user could focus on a thread, a process, or a file (or sets thereof); and have a generalized "focus-group apply" thing. 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.) Finally, HPD also has "barrier"s, which are like multi-process breakpoints. I don't know if these are interesting enough to write into the core of gdb; it seems to me that new porcelain like this can most easily be put over the plumbing using new commands written in python. 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? 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. Tom