Re: Multiprocess GDB, formal spec

[Stan Shebs <stan@codesourcery.com>]

Tom Tromey wrote:
>>>>>> "Stan" == Stan Shebs <stan@codesourcery.com> 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 '[<spec>]', where
> Stan> <spec> 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> [<name>]
> Stan> Specifies the named itset <name>.
> Stan> [<exec>]
> Stan> Specifies the default inferior corresponding to the program named <exec>.
>
> 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 #<inf>#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