> Wouldn't it be better to fix them all, by making ktracers find out
> about data the kernel reads from places pointed to by syscalls?  Then
> kdump can juggle the formatting however it thinks appropriate for the
> call in question.  Yes, this means a bit more work (syscalls that chase
> user-level pointers would have to use a routine that creates ktrace
> entries as well as reading the data), but it's really the right fix.

I had ideas about this, but it would be a bit intrusive.

Working at the syscall code level seems unworkable, because you don't
know if the argument given to the syscall will actually be used.

IMO the right place to trace things is at copyin/copyout level:

We can introduce a new copyin/coypout set of function, let's say
dcopyin/dcopyout:

inline int 
dcopyin(l, uaddr, kaddr, len, type)
        struct lwp *;
        const void *udaddr;
        void *kaddr; 
        size_t len;
        int type; 
{

        error = copyin(uaddr, kaddr, len);
#if KTRACE
        if (!error && type && KTRPOINT(l->l_proc, type))
                ktrgeneric(l, type, UIO_WRITE, kaddr, len);
#endif
        return error;
}

ktrgeneric() would save in the ktrace record the type, the read/write
direction and the data. kdump would use the type to learn how to format
the data. There could even be a set of data displaying function shared
among kdump and kernel.

Then the next job would be to gradually replace every copyin/copyout in
the kernel by the typed version dcopyin/dcopyout

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@netbsd.org