Re: Multiprocess GDB, formal spec

[Tom Tromey <tromey at redhat dot com>]

>>>>> "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 :-)

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.

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 <itset>
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 #<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?

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