From owner-freebsd-hackers Thu Jan 29 15:12:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA13625 for hackers-outgoing; Thu, 29 Jan 1998 15:12:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA13546 for ; Thu, 29 Jan 1998 15:12:35 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.7) id PAA11062; Thu, 29 Jan 1998 15:12:09 -0800 (PST) (envelope-from sef) Date: Thu, 29 Jan 1998 15:12:09 -0800 (PST) From: Sean Eric Fagan Message-Id: <199801292312.PAA11062@kithrup.com> To: dcs@gns.com.br Cc: hackers@FreeBSD.ORG Reply-To: hackers@FreeBSD.ORG Subject: Re: TRUSS In-Reply-To: <199801292256.UAA01019.kithrup.freebsd.hackers@daniel.sobral> Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe hackers" In article <199801292256.UAA01019.kithrup.freebsd.hackers@daniel.sobral> you write: >I was playing with truss today, and used it against the program that >tests my device driver. Surprisingly, it didn't work. Is it possible >that truss interferes with the normal operation of the driver, or >should I assume there is, indeed, a bug that does not appear under >any other conditions (so far tested)? truss *may* cause problems, timing wise -- the target process is stopped until it is restarted, and that may be a problem in your case. Without more information, I can't quite say, I'm afraid. But, by itself... no, I can't see truss causing any real problem. It causes the process being traced to stop on system call entry, and system call exit. What do you mean by, "it didn't work"? (That is, how didn't it work?) >BTW, I noticed truss gives me hex numbers for all read() parameters, >but decimal numbers for the first and the third parameters of >write(). Mainly because I haven't done anything about read(). If you take a look at /usr/src/usr.bin/truss/syscalls.c (I think it is), there's an entry in the array for write(), but not read(). By default, truss will print out arguments in hex, if it doesn't know any better -- and it can't know any better unless someone tells it ;). It's easy enough to change; read() would look something like: { "read", 1, 3, { { Int, 0}, { Ptr|OUT, 1}, { Int, 2}}}, (which breaks down to: syscall "read", returns a single value, takes three arguments; they are an int at offset 0, a ptr that is modified by the syscall at offset 1, and an int at offset 2. "Int" is printed out in decimal, and Ptr's are printed out as hex).