This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Multiprocess GDB, formal spec
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