Re: Towards multiprocess GDB

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Stan" == Stan Shebs <stanshebs@earthlink.net> writes:

Stan> CodeSourcery has a project to add "multiprocess" capability to GDB,
Stan> and with this message I'd like to kick off some discussion of what
Stan> that means and how to make it happen.

Awesome.

Stan> Once the debugger is started, but before any of the programs
Stan> have run, it seems obvious to have a notion of "current
Stan> program", so that commands like "list main" and "break main"
Stan> will work as usual.

Stan> Notice that we don't really want to use the term "process" for any of
Stan> this so far, because nothing is running yet and there are no
Stan> processes/inferiors; this part is all about the symbol side.

It is worth thinking about how things like "break main" will work
after processes have been made, as well.  For instance, consider
something like "set follow-fork-mode both"; after a fork, where does
'break main' apply?

This is particularly interesting if you are watching a very large tree
of processes.  It would be nice if gdb did not have eagerly to read
symbols for every program.

The HPD spec (which I know you worked on :) has some "focus" commands
for this kind of thing.  It may be worth looking at that, or looking
to see what the competition (totalview cough cough) does.  I suppose
the user could focus on a thread, a process, or a file (or sets
thereof); and have a generalized "focus-group apply" thing.

Another idea, related to something in HPD, would be to come up with a
general syntax for naming things -- like "#PID#file.c:function" (or
what have you) -- so the user can easily embed a context into a name.
(I dunno if this is useful, I'm just brainstorming a bit.)

Finally, HPD also has "barrier"s, which are like multi-process
breakpoints.  I don't know if these are interesting enough to write
into the core of gdb; it seems to me that new porcelain like this can
most easily be put over the plumbing using new commands written in
python.

Stan> Conversely, the user will also want a way to take programs out
Stan> of the debugging session. This is not quite the same as
Stan> detaching, because the user may want, say, the server to
Stan> continue doing its serving thing

I don't understand the distinction here.  With 'detach' the server
would continue serving... what am I missing?

Stan> Although my inclination is to create a new symbol table for each
Stan> process' image of each shared library, that may be excessively
Stan> expensive.

To me this sounds important to solve, though of course I have no
numbers.  I am just thinking that every program is going to be mapping
in libc, and it would be great to scale to a large number of inferiors.
FWIW the particular scenario I am interested in is running "make check"
in the gcc tree, under gdb, and having it stop only when some
sub-process gets a SEGV.  So, the question is, how does gdb react to
thousands of process creations and deletions, how eagerly does it read
and discard symbol table info, etc.

Tom