From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13866 invoked by alias); 14 Aug 2008 19:49:58 -0000 Received: (qmail 13856 invoked by uid 22791); 14 Aug 2008 19:49:57 -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; Thu, 14 Aug 2008 19:49:23 +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 m7EJjA8B020617; Thu, 14 Aug 2008 15:45:10 -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 m7EJjAsa027228; Thu, 14 Aug 2008 15:45:10 -0400 Received: from opsy.redhat.com (vpn-10-34.bos.redhat.com [10.16.10.34]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m7EJj9xq009424; Thu, 14 Aug 2008 15:45:09 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id DE0B7378294; Thu, 14 Aug 2008 13:45:13 -0600 (MDT) To: Stan Shebs Cc: gdb@sourceware.org Subject: Re: Multiprocess GDB, formal spec References: <48A35D22.30705@codesourcery.com> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Fri, 15 Aug 2008 13:13:00 -0000 In-Reply-To: <48A35D22.30705@codesourcery.com> (Stan Shebs's message of "Wed\, 13 Aug 2008 15\:16\:02 -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-08/txt/msg00182.txt.bz2 >>>>> "Stan" == Stan Shebs writes: Stan> The following writeup is a more formal specification for Stan> multiprocess GDB. I read this. I like it a lot. I have a few comments -- nothing too major though. Stan> The command-line syntax for inferior/thread sets is '[]', where Stan> may take several forms. I know this comes from HPD. I wonder if maybe "inferior apply" would be more gdb-ish? Or even just "focus [itset] command"? (I sort of hesitate to mention this, due to its bikesheddy nature. If it helps I dropped most of my commentary on the names of other things :-) Stan> [] Stan> Specifies the named itset . Stan> [] Stan> Specifies the default inferior corresponding to the program named . I'm a bit cautious here due to possible ambiguities. Perhaps we don't care since names are assigned by the user.. ? Do we want an explicit name for the current itset? Stan> [TBD: Allow '[]' to be optional when it is unambiguous, as in Stan> focus command?] Yeah, I think so, at least as long as that is all that "focus" does. Stan> focus Stan> Sets the effect of subsequent commands to apply only to the inferiors Stan> and threads in the given itset. This set is known as the "current" itset. I think there has to be an implicit focus around breakpoint commands (this comes a bit later in the spec). But actually, this is kind of a weird area. Should a breakpoint command be able to change the focus for the CLI? Or should the commands push a focus, then pop it after the commands are done? ISTR some other thread touching this topic recently. Stan> set follow_exec true Maybe a "-" instead of "_", for consistency with follow-fork? Stan> For instance, "break main" can cause every program under GDB's Stan> control to stop soon after it starts; to break in only some Stan> executables, the syntax "break ##main" would be necessary. I am curious how I would go about setting a breakpoint in an inferior that doesn't exist yet. E.g., suppose I want to run gcc and break at a function in cc1. Would I "add-file /dir/cc1" and then "break #cc1#function"? And then gdb would hold this as a kind of pending breakpoint until a cc1 actually starts? Stan> [TBD: have a way to delete "locations" from a breakpoint? too Stan> complicated?] If we had a name for the current itset, you could do: [all] break #[current]#main ... to set individual breakpoints on each main. That would make each one individually manipulable. Stan> When one of the inferiors/threads stops, GDB sets the current Stan> itset to consist of just the inferior and thread that actually Stan> stopped. The user is free to change the focus thereafter. I wonder about the UI here. Suppose I am debugging many programs, all running async. And, I have my focus on one particular one, which I have stopped. Then, some background program hits a breakpoint. In this case, I am already typing away at the gdb prompt -- so, having the itset change immediately would seem unfriendly. I could easily end up typing commands at an inferior other than the one I thought I was working on. So, maybe in the async case gdb should just print a notification, e.g.: Inferior stopped, type "focus 5" to focus. I don't think this is a problem if programs are running synchronously. In fact there it would be better to set the focus automatically when the inferior stops, just because that is what everybody is used to. Stan> info program Stan> Displays the status of each inferior currently in existence, including Stan> whether it is stopped and why. Is this different from "info inferior"? Stan> ** Planned limitations of the first version Thanks for being explicit about this. Tom