[RFC] multi-process gdb (forks, checkpoints)

[RFC] multi-process gdb (forks, checkpoints)

[Michael Snyder]

Folks, I'm pretty close to actually submitting this for approval;
this is (knock on wood) my last request for pre-review.

Instead of attaching a patch, I've checked this in on a branch:
msnyder-fork-checkpoint-branch.

This is, no kidding, gdb debugging multiple processes.
I've adapted it to work with the existing "follow-fork"
infrastructure, so that when a process forks, instead of
being forced to choose between debugging the parent or the
child, we can now debug both.  The user sets a mode flag,
and rather than detaching from one of the forks, gdb will
set it aside (in a ptrace-stopped state), and let you
return to debugging it later, switching back and forth
at will.

Daniel, it handles quit, kill, and inferior exit.
If one process exits and there's another available,
it just switches automatically (as it would with threads).

I've added a testcase, gdb.base/multi-forks.exp, which serves
to demonstrate the debugging of 16 forks at a time.

And of course checkpoint and restart are in there too.

Eli, I'll be working on documentation.  For the mean time,
the user interface looks like this:

	set/show detach-on-fork (on/off) [default on]
	info forks
	fork <n> [analogous to thread <n>]
	detach-fork <n>
	delete-fork <n> [and kill]

	checkpoint
	restart <n>
	info checkpoints
	delete-checkpoint <n>
	detach-checkpoint <n> [well...]

Re: [RFC] multi-process gdb (forks, checkpoints)

[Eli Zaretskii]

> Date: Mon, 28 Nov 2005 14:57:51 -0800
> From: Michael Snyder <msnyder@redhat.com>
> 
> This is, no kidding, gdb debugging multiple processes.

Wow!  Thanks!

> Eli, I'll be working on documentation.  For the mean time,
> the user interface looks like this:
> 
> 	set/show detach-on-fork (on/off) [default on]
> 	info forks
> 	fork <n> [analogous to thread <n>]
> 	detach-fork <n>
> 	delete-fork <n> [and kill]

I'd prefer that we use ``process'' instead of ``fork'' here.  That is,

    info processes
    process <n>  [assuming n is a PID]
    detach-process <n>
    delete-process <n>

Re: [RFC] multi-process gdb (forks, checkpoints)

[Michael Snyder]

Eli Zaretskii wrote:
>>Date: Mon, 28 Nov 2005 14:57:51 -0800
>>From: Michael Snyder <msnyder@redhat.com>
>>
>>This is, no kidding, gdb debugging multiple processes.
> 
> 
> Wow!  Thanks!
> 
> 
>>Eli, I'll be working on documentation.  For the mean time,
>>the user interface looks like this:
>>
>>	set/show detach-on-fork (on/off) [default on]
>>	info forks
>>	fork <n> [analogous to thread <n>]
>>	detach-fork <n>
>>	delete-fork <n> [and kill]
> 
> 
> I'd prefer that we use ``process'' instead of ``fork'' here.  That is,
> 
>     info processes
>     process <n>  [assuming n is a PID]

Good idea.  But <n>, as written, is not a PID, it's a
small counting number (analogous to a breakpoint id or
thread id).

I've added the command "process <proc-id" on the branch,
but kept "fork <fork-id>" since its semantics is different
(and still useful).  "info processes" is problematic, since
there is already an "info proc" command.

Re: [RFC] multi-process gdb (forks, checkpoints)

[Jim Blandy]

What happens if we fork, and then one of the forks unloads or loads a
shared library?

We're really crippled by our symtab data structures.

Re: [RFC] multi-process gdb (forks, checkpoints)

[Michael Snyder]

Jim Blandy wrote:
> What happens if we fork, and then one of the forks unloads or loads a
> shared library?
> 
> We're really crippled by our symtab data structures.

Hmmm... unload would be the bigger problem, I suppose.

I'd look at it this way -- this is really a subset of "debugging
separate processes".  The subset is, processes that share the same
symbol set.  What you suggest is crowding that boundary.   ;-)

We know that the set of programs that can be debugged this way
is prescribed.  Can't do multi-threaded programs, for instance.

Re: [RFC] multi-process gdb (forks, checkpoints)

[Daniel Jacobowitz]

On Tue, Nov 29, 2005 at 05:58:43PM -0800, Michael Snyder wrote:
> Jim Blandy wrote:
> >What happens if we fork, and then one of the forks unloads or loads a
> >shared library?
> >
> >We're really crippled by our symtab data structures.
> 
> Hmmm... unload would be the bigger problem, I suppose.

Yes.  Eventually we just need to improve the symtab interface enough to
permit this.  I think it's not an unreachable goal.  The user interface
is going to get thornier and thornier, though.

> I'd look at it this way -- this is really a subset of "debugging
> separate processes".  The subset is, processes that share the same
> symbol set.  What you suggest is crowding that boundary.   ;-)
> 
> We know that the set of programs that can be debugged this way
> is prescribed.  Can't do multi-threaded programs, for instance.

Right - we can't duplicate them - we could more or less fake it, but
they know too much about their TIDs, and their TLS, et cetera.

-- 
Daniel Jacobowitz
CodeSourcery, LLC