Subject: Re: Intercepting system calls
To: None <email@example.com>
From: None <firstname.lastname@example.org>
Date: 04/24/2002 18:18:35
| On Wed, Apr 24, 2002 at 03:32:26PM -0000, email@example.com wrote:
| > | 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.
| No - because IIRC all the instructions on how to format the data
| are embedded in the kernel for ktrace, whereas truss only requires
No, they aren't. The kernel ktrace simply packages up the
sycall parameters or syscall return code into a structure that
is then written to a file. This work is always done in the
syscall entry code anyway since the arguments need to be stuffed
into the syscall's arg structure. Conversion to strings is done by
| that the kernel stop the process on system call entry/exit.
Truss also requires gathering syscall arguments (unless you
need to explicitly use separate ptrace calls to read/write
the target's register contents or stackframe which adds even
| > | 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.
| Try the UnixWare 2/7 one - loads of commands for displaying
| various system data structures. Get the kernel stack
| trace for an active process (to see where it is sleeping).
| I have enhanced it to load additional (eg driver specific)
| commands from shared libraries found in a specific directory.
| That way you can write a device driver, dynamically load it
| and debug it's data strcutures....
As I said, not as flexible as gdb on the kernel which uses
stabs/DWARF info created by the compiler to allow you to
dump just about any datastructure in the kernel.
| > OTOH, I miss (k)adb.... With a decent set of macros it's
| > much more useful than ddb.
| Ah yes, macros that are exceptionally version specific and too
| terse to understand with limited methods of displaying output.
| Writing the print code in C gives you MUCH more flexibility.......
Automagically generating macros from stabs/DWARF info or C header
files (what Solaris does) is SMOP.