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
that the kernel stop the process on system call entry/exit.
The extra process switches do slow things down, but, for instance,
you can combine it with a debugger to breakpoint at next system
call, or run special code that only starts tracing after some
specific event...
> 
> | 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....
> 
> 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.......

	David

-- 
David Laight: david@l8s.co.uk