Re: kern/43611: kernel-trace (via ktruss) reports wrong parameter/result values

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/43611; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/43611: kernel-trace (via ktruss) reports wrong
 parameter/result values
Date: Thu, 15 Jul 2010 20:13:45 +0000

 On Wed, Jul 14, 2010 at 12:40:03PM +0000, Christos Zoulas wrote:
  >|>  ktruss probably should be rewritten to use system call entry/exit
  >|>  breakpoints and then userspace controlled reads of the traced programs
  >|>  memory (which is how truss works on SYSV).
  >|  
  >|  Using ptrace for this purpose is not desirable because it monkeys with
  >|  the parent/child process relationships and tends to break things,
  >|  particularly shell scripts.
  >  
  >  It is desirable because it stops the process and lets you examine the
  >  syscall arguments in detail.
 
 Mm, point. Maybe we ought to invent a new kind of tracing for this
 purpose (since supervised execution was trendy in research for a while
 and it's getting to the point of moving to production...)
 
 I'm not sure if it makes sense for that to be different from a
 debugger interface or not.
 
  >  |  (I'm not particularly clear on exactly what ktruss does that's
  >  |  different from running kdump afterwards, but then I've never been
  >  |  particularly clear on why ktruss is desirable relative to running
  >  |  kdump afterwards, either.)
  >  
  >  Interactivity; you can watch processes that stop and wait for events
  >  and see what they do as you supply the different events.
 
 Ah. Yeah, I guess that can be useful. The main problem I've always had
 with strace and truss and whatnot is that the trace output gets mixed
 with the program's output; when I first found ktrace years ago it was
 a big step forward.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost