From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22363 invoked by alias); 14 Aug 2008 20:39:24 -0000 Received: (qmail 22352 invoked by uid 22791); 14 Aug 2008 20:39: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; Thu, 14 Aug 2008 20:38:36 +0000 Received: (qmail 16673 invoked from network); 14 Aug 2008 20:38:34 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Aug 2008 20:38:34 -0000 Message-ID: <48A497BF.4070107@codesourcery.com> Date: Fri, 15 Aug 2008 15:02:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: tromey@redhat.com CC: Stan Shebs , gdb@sourceware.org Subject: Re: Multiprocess GDB, formal spec References: <48A35D22.30705@codesourcery.com> 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-08/txt/msg00184.txt.bz2 Tom Tromey wrote: >>>>>> "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 :-) > One of things I noticed about thread apply is that it really depends on threads being numbered, whereas inferiors in general can be named or numbered. So we're going to get roped into some sort of alternate syntax one way or another. This is the right time to talk about syntax in any case, don't want future generations cursing us because we saddled them with something lame. :-) > 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. > Yeah, I imagine we can set up a reasonable priority rule, such as "itset names first" - execs can always be referred to by partial path if an itset name manages to mask one. I don't have any intuition about a best rule. > Perhaps we don't care since names are assigned by the user.. ? > > Do we want an explicit name for the current itset? > One would think so - oddly, I can't seem to find any notation for it in the HPD spec. (Perhaps because it's always implicit?) > 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? > An interesting question... > ISTR some other thread touching this topic recently. > > Stan> set follow_exec true > > Maybe a "-" instead of "_", for consistency with follow-fork? > I scrubbed follow-exec, Pedro showed me it was a brain cramp. :-) > 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? > Pending breakpoint seems right, that way you don't have to know ahead of time which of the many cc1's lying around is going to be the one that gets executed. > 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. > That assumes the prefix syntax temporarily alters the current itset from the user has been using. It's almost like one wants a [this] itset, that automagically consists of the one inferior that is the iterator in the prefix syntax. > 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. > That sounds right, I'll incorporate. > 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"? > I'm thinking of "info inferior" as displaying all inferiors, including those that are setting up argument lists but not have run yet, while "info program" is a generalization of the current behavior, displaying only inferiors that have started execution but not finished. Stan