Message passing

[Jonathan Shapiro]

   That's already provided, because the trap/syscall instruction that
   invokes the kernel message passing mechanism is considered "one
   instruction".  You can single-step across it or set a breakpoint
   immediately after it, and the entire message send/receive operation
   will occur during the execution of that single syscall instruction.

This is a bit off the topic, but possibly relevant to our discussion
of process models.  I'm not trying to advance it as a better way to do
things, but possibly there are worthwhile ideas in the UNIX process
model that can be borrowed for DIMSUM and mach4.

The UNIX Debugger work at AT&T motivated the design for syscall
entry/exit trapping in the /proc(4) interface (Killian, Faulkner, and
Gomes).  The work was later picked up and extended by my group at SGI
in the VIEW debugger to do fast data breakpoints (me).

In the SVR4/Solaris UNIX process models, there are four events of
interest (perhaps they should be called sequence points) relevant to
single-stepping a system call:

1. The instant before the trap instruction is stepped (i.e. the PC
   where if you were to perform single step you would execute the trap
   instruction.

2. The instant just before  the system call is dispatched within the
   kernel (a syscall entry trap).  This is just inside the kernel.  It
   occurs after the process has entered the kernel but before the trap
   request has been interpreted.  The kernel knows that it is to
   handle a system call, but has not yet decoded which one.

   The debugger is free at this point to change the process registers
   in a way that forces the kernel to perform a different system call,
   and/or to capture the argument info for tracing.  It can also abort
   the system call.  If an abort is done and a syscall exit trap is
   active, the abort has the effect of moving the process to the
   system exit trap point within the kernel without actually executing
   the system call.

   This even happens at most once.  Restartable system calls restart
   from just after this event of interest.

3. The instant just before the system call completes in the kernel.
   At this instant, the kernel has produced the result of the system
   call, and is just about to return to the process.  The debugger is
   free to change the return value or any other process register.

4. Single step completion.  At this point the trap call has been
   completed.

The model relies, in some sense, on the atomicity of UNIX system calls
(which isn't good or bad; I'm just noting it for discussion).  When
page fault tracing was added later on by Faulkner at Sun this grew
quite a bit more complex.

Syscall entry/exit trapping had a lot of uses.  The two most important
were call tracing and environment emulation.  We actually went so far
as to use this mechanism to emulate a previous generation of the
operating system in a binary compatible fashion.



Jonathan