A while ago, I implemented syscall tracing (a la SunOS PTRACE_SYSCALL)
for NetBSD/sparc.  At the time I sent it to a couple of people, but it
seems to have been filed for later attention, and later never arrived.
I just today exchanged mail with pk about it; the upshot was that most
of it was not SPARC-specific, so why not send it to tech-kern?

Hence this note.  I am still running 1.0 (I've been meaning to move to
current, but haven't yet), and my patches are to 1.0.  A quick skim of
current source makes me think there isn't much difference in the
relevant files, though.  I actually implemented two new requests,
PT_SYSCALL (akin to SunOS PTRACE_SYSCALL) and PT_BLK, which provides a
block I/O request akin to using SunOS PTRACE_{READ,WRITE}{TEXT,DATA}
with their ptrace()'s fifth argument.  The former is implemented as an
architecture-specific request, the latter as architecture-independent.

pk also remarked that it might be cleaner to do this via procfs
instead.  procfs has some security problems that I'd want to address
before I'd build anything serious like a syscall tracing utility on it;
also, I've corresponded with one or two people about it and get the
impression it's a very optional subsystem, with a "use at your own
risk" tag.  Of course, putting this tracing in procfs could end up
tightening up procfs a good deal, which would probably be a Good Thing.

Regardless, though, what I have is ptrace()-based.

This note is intended more to provoke discussion than to get anything
into the tree, though if someone wants to pick up the patches and check
them in I certainly won't object. :-)  One possible thing that might be
worth discussion is some mechanism to support tracing only a subset of
the syscalls.  If any sort of consensus is reached (including deafening
silence), I'll probably package up the result and send-pr it as an
enhancement request.  I'm hoping that by that point I'll have -current
installed, so that I can provide a patch tree relative to -current as
well as to 1.0.

Only a handful of files get touched:

sys/arch/sparc/include/proc.h
	Add a new element to struct mdproc, that element serving as the
	user-land interface.

sys/arch/sparc/include/ptrace.h
	To define PT_SYSCALL for the SPARC.  (This goes here rather
	than in sys/ptrace.h because I wanted to define it only for
	architectures that implement it.  If a significant number of
	the ports pick it up, it might be better to move it to
	sys/ptrace.h instead.)

sys/arch/sparc/sparc/process_machdep.c
	Define a small helper function that provides controlled write
	access to the struct mdproc, for PT_WRITE_U.

sys/arch/sparc/sparc/trap.c
	One of two files with relatively voluminous changes.  This is
	where the hooks into the syscall mechanism are.

sys/kern/sys_process.c
	The other file with relatively voluminous changes.  This is
	where ptrace() is implemented.

sys/sys/proc.h
	To add a flag, P_PTSYSCALL, that's set on a process to indicate
	that it's syscall-tracing.  sparc/trap.c looks at this flag in
	syscall().

sys/sys/ptrace.h
	To define PT_BLK and the associated struct.

lib/libc/sys/ptrace.2
	To document PT_SYSCALL and PT_BLK.

lib/libc/sys/Makefile.inc
	To get it to build ptrace.0.

I've also ported (rewritten, really) my SunOS syscall tracer to use
these NetBSD facilities.

I'll be glad to email any desired subset of the above to anyone who
cares.  The patches are also up for anonymous ftp, from 132.206.78.1 in
/mouse/netbsd-patches/1.0 (that directory contains all[%] the patches
to 1.0 that I run with, which is more than just the ptrace() changes).
The syscall tracer program is there in /mouse/netbsd-trc.tar.gz, but I
don't know how portably written it is; if you have trouble building it
please feel free to send me mail.

[%] Almost all.  I've removed lib/libcrypt/descrypt.c, since I don't
    need export-control headaches.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu