question about dbx and fork(2)

[Chris Torek]

In article <2340 at pdxgate.UUCP> jrb at jove.cs.pdx.edu (James Binkley) writes:
>This was done on a Sun 4.1 system.  The machine is a 68020. ...
>I then singlestep past the fork ... [and find that] the child died courtesy
>of a SIGTRAP plus a core file was generated.

If the machine were a SPARC you would have to put up with this, but it
is not so you do not, but to fix it you will need sources.

fork() copies the memory image of the parent process, which means it
copies any breakpoint instructions that dbx or gdb has installed.  If
there is such a breakpoint just `after' the fork, the child process
will hit the breakpoint and die with a SIGTRAP.

>gdb 3.5 on the same machine does not exhibit the
>same behavior; i.e., wait() blocks as one would expect.

Most peculiar.

Single stepping, on the 68020, is done by setting the T bit in the
PSR.  If the fork code fails to clear the T bit in the child's PSR, any
parent that is being stepped would cause the child to step and thus
trap.  Since gdb does not cause a trap, we can presume that the kernel
got this right.  Chances are, then, that dbx left a breakpoint
somewhere.  (Examine the PC in the child's core dump to verify this.)

Single stepping on the SPARC is more interesting, as there is no T bit.
Debuggers must plant breakpoints at all of the possible `endpoints'
of each instruction, then run the process for that single instruction
(plus the breakpoint).  This means it is impossible to single step
across fork() on a SPARC.

In general, debugging processes that fork is tricky.  The usual approach
is to replace (temporarily) the fork with `pid = 0' or `pid = 12345' so
as to run just the parent or child code.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov