| On Wed, Apr 24, 2002 at 03:32:26PM -0000, eeh@netbsd.org 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
kdump later.

| 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
more overhead.)

| > | 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.

Eduardo