>>> besides format, and libkvm programs, what else is there that
>>> doesn't work ?
>> trace(1) comes to mind immediately, since syscall ptracing is near
>> and dear to me.  (I _really_ ought to find the time to port those
>> changes to -current....)

> One thing about trace(1) which has always bothered me (which system V
> (there's that 'S' word again! :-) has taken care of, in truss(1m)) is
> that if the traced process forks, you can give up any hope of finding
> out what is going on unless you're *really* fast with a command line!

> Has anyone implemented any new advances into trace(1) such that you
> can tell it to follow children as they are created?

Under SunOS?  I tried, once.  I have my own trace(1)-like program,
written to fix the problems trace(1) has with programs that manipulate
(eg, block) SIGTRAP; I modified it to patch an infinite loop into the
executable just at the point the syscall would return to, so the
tracing process could attach to the new child.  Turns out the child
process gets a copy of the _unpatched_ text segment under these
circumstances. :-(

My ptrace patches for 1.0 do provide enough support to trace through
forks.  Not directly, but rather it allows the tracing process to cause
the traced process to not actually execute the syscall, instead just
seeing return values as provided by the tracing process.  Thus, a
trace(1)-like program could be built which, when it sees the child
fork, shorts-circuits the syscall, forks itself, execs the image again,
clones the stack and data segments, and fakes the parent/child
relationship by fudging return values from getppid() and the wait*()
family of calls.

It wouldn't be easy to do, mind you; it might be better to provide a
way to cause forked processes to be automatically acquired by the
tracer of the forking process.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu