Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!csd4.milw.wisc.edu!uxc!deimos!rutgers!att!lzaz!bds
From: bds@lzaz.ATT.COM (B.SZABLAK)
Newsgroups: comp.os.minix
Subject: Re: Trace System call for Minix
Summary: ptrace, printf, I/O difficulties
Message-ID: <349@lzaz.ATT.COM>
Date: 6 Jan 89 14:23:46 GMT
References: <6255@louie.udel.EDU>
Organization: AT&T ISL Lincroft NJ USA
Lines: 26


Recently I posted a version of ptrace() for the ATARI ST. It should not
be too tough to get working on the PC version I should think. One issue
I faced was whether to permit single stepping into the kernel when an
application does a system call. It turns out that for the ATARI ST
version (at least) this would become a boondoggle. I'd have to have the
code infront of me again to go into detail. So I punted and suspended
single stepping until after the system call returns. As a result the
single step execution of a trap instruction does not return until the
trap and the instruction in the application that follows the trap is
executed.

Your example of debugging the FS process would not be feasible from
an application since all application I/O goes through the FS process.
If the FS is halted (as at a break point) how can it service I/O requests?

What could be done is to create a kernel task that would monitor the
usage of mini_send() in the kernel. A system call could be used (or
a keyboard escape sequence) to turn on tracing of message handling;
a log of source task, destination task, and message type would be useful
and enlightening.

Finally, I've seen reference to a debugger that is integrated into the
kernel (as I understand it), and thus not as restricted as an application
program. Sorry, I have no more info. For me, printf's in the kernel
suffice when needed.