jnall%FSU.BITNET@cunyvm.cuny.edu (John Nall 904-644-5241) (01/06/89)
As part of a questionnaire that I gave my Fall class in Operating Systems, which uses Minix for lab exercises, I asked for ways in which the course might be improved. One response was that it would help students to learn how the operating system works if there were some sort of trace function in Minix -- some way to "step through" the system. It occurs to me that this would not only be nice, it should not be very hard to do. Essentially, a "trace" system call would be added, and the student would use it at points where he needed to stop the world and look at it. That is, a student might put such a system call in a strategic place within fs, and build a new system. When it was booted up, it would enter trace mode when it got to that point. The system call itself would essentially just be the logical equivalent of a breakpoint call in debugging an application program. That is, it would allow the display of certain items, give certain information, etc. At some point, the student could do a GO and continue normal operation. Before I reinvent the wheel (or try to get a grad student to do it), has anyone already done this? Or are there some real show stopping problems that I'm just not seeing?? Thanks for the help. John Nall (jnall@rai.fsu.edu BITNET) Computer Science Department Florida State University
bds@lzaz.ATT.COM (B.SZABLAK) (01/06/89)
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.
rsnider@xrtll.UUCP (Richard Snider) (01/08/89)
In article <6255@louie.udel.EDU> jnall%FSU.BITNET@cunyvm.cuny.edu (John Nall 904-644-5241) writes: >how the operating system works if there were some sort of trace function >in Minix -- some way to "step through" the system. > >It occurs to me that this would not only be nice, it should not be very >hard to do. Essentially, a "trace" system call would be added, and the >student would use it at points where he needed to stop the world and look >at it. >Before I reinvent the wheel (or try to get a grad student to do it), has >anyone already done this? Or are there some real show stopping problems >that I'm just not seeing?? > >Thanks for the help. > >John Nall (jnall@rai.fsu.edu BITNET) The problem with allowing the system to "Stop" and then letting someone take some time to check things out is that Minix depends heavily on various interrupts happening to do such things as turn disk drives off, watch the keyboard, and process switching and servicing. The only approach that I can suggest is that you implement some sort of processor trap which saves the state of the machine in some known place (Maybe a special /dev type file) where you can read it out. Now this isn't exactally what I would call a Trace but it at least will give you some idea of what is going on at exactally that place in the code. The other approach I can see is to write some sort of processor emulator which when given the information about contents of registers and memory (at the present time) by some call as described above, it will then go on and appear to be the machine to the student so that they may single step it or change things and continue...etc. This of course is not perfect since you will have to save the values at all the device io address along with the processor state so that they may be referenced by the emulator. But since we are talking about a teaching tool here, it may be suffcient. Best of luck. Richard Snider ------------------------------------------------------------------------------- Where: ..uunet!mnetor!yunexus!xrtll!rsnider Also: rsnider@xrtll.UUCP "Hey ! Whats with all the blue lines on the RGB Monitor ???" "Ummm.....Looks like.....well....Ethernet!"