Date: 17 Oct 2001 04:01:55 +0200 From: Dag-Erling Smorgrav <des@ofug.org> To: Jim Pirzyk <Jim.Pirzyk@disney.com> Cc: freebsd-hackers@freebsd.org Subject: Re: truss vs ktrace Message-ID: <xzpofn7vxbg.fsf@flood.ping.uio.no> In-Reply-To: <3BCCCF74.75B7F36C@disney.com> References: <3BCCCF74.75B7F36C@disney.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jim Pirzyk <Jim.Pirzyk@disney.com> writes: > So which should I use? Why is there two around? I see that truss has > less command line switches than ktrace, but it is a little bit more > standard. - truss slows down the slave process a *lot* as the slave process stops at every syscall and waits for truss to notice, obtain and process information (a task which in itself requires a bunch of additional context switches and syscalls) and print its output. This also means that if you pipe truss through less and don't page down fast enough, the slave process will hang waiting for truss which is waitig for less to absorb its output. - truss currently can't follow forks and trace children of the original process. This should be fixable, though. ktrace doesn't (as far as I know) noticeably slow down the traced process, and can follow forks, and provides some types of information truss doesn't (like namei translations and context switches). On the other hand, it can't display detailed information about syscall arguments the way truss does (but truss needs to stop the traced process to do this, and can only do it for syscalls it's been taught how to decode). I generally find ktrace more than adequate (and often superior to truss), because I can generally work around the need for examining syscall arguments by instrumenting the program I'm debugging, or the kernel itself. If I were debugging a program to which I didn't have source code, I might prefer truss. (ktrace is actually a lot more powerful than it looks on the surface - it has provisions for letting the traced process add information to the trace, and is designed so that one can add new information types without breaking compatibility with older versions of ktrace and kdump - it is conceptually possible to extend ktrace to include the contents of syscall arguments in the log, at least for selected syscalls, like truss does. A junior kernel hacker task maybe?) > I also see that truss works with the linux syscalls where ktrace does > not remap the syscall names. It's not ktrace's business to remap anything. That's kdump's job, and there is a linux_kdump utility in ports that will do what you want. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpofn7vxbg.fsf>