Subject: Re: Intercepting system calls
To: None <email@example.com>
From: None <firstname.lastname@example.org>
Date: 04/24/2002 15:32:26
| On Mon, Apr 22, 2002 at 09:09:42PM -0700, John Clark wrote:
| > There is a tool in linux, 'strace' which allows one to
| > trace system calls. I've used it on rare occasions, when
| > I though some particular system call was causing a
| > kernel panic.
| Also the Solaris and SVR4 'truss'.
| The advantage of a user space trace of system calls is that you don't
| have the overhead of all the code being permanently resident.
| It also makes it easier to humanise the output for ioctl (etc)
| requests. (When you can't understand the output, you just rebuild
| the program - it was just a large heap of printf() calls).
You still need instrumentation in the kernel to intercept the
system call, so the amount of kernel code used by ktrace and
truss should be pretty much the same.
| There is, similarly, a lack of a 'crash' program that can be used
| to display data structures etc from the running kernel and/or
| a system dump. kadb (etc) are just too user unfriendly - even
| for Unix.
crash is no where near as flexible as gdb. It's also only
useful for tracking down memory leaks, and then only if the
kernel has the memory tracking code turned on.
OTOH, I miss (k)adb.... With a decent set of macros it's
much more useful than ddb.