#: From owner-port-sparc@NetBSD.ORG Wed Sep 20 12:26:50 1995
#: Date: Wed, 20 Sep 1995 13:31:59 -0400
#: From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
#: To: port-sparc@NetBSD.ORG
#: Subject: Re: -current/4110
#: 
#: > 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....)
#: 
#: 					der Mouse

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?  It's really a bother
watching a process go:

getpid() =				3392
vfork() =				3400

and then sit and pause while the child does something, but not long enough
to start another trace on pid 3400.

Does the process tracing subsystem need an overhaul?


				--*greywolf;

#: 
#: 			    mouse@collatz.mcrcim.mcgill.edu
#: