debugger v. domain keeper

[Landau, Charles]

Your proposal is unnecessary. As usual, an elegant solution falls out of the
KeyKOS architecture.

A process's domain keeper key is merely the first object to get a crack at
handling a process's faults. If there are faults it doesn't handle, it can
and should pass them along to the next keeper in the chain. 

When a domain keeper is installed, the installer should save the old keeper
for use as the next in the chain. The debugger does this, and it had (or
should have had) a command to pass a fault on.

The Unix emulator was an example of a domain keeper than handled certain
faults and passed others on. This made it possible to debug a Unix process
without the debugger seeing Unix system calls. Of course, you could arrange
to install the keepers in the other order, if you wanted to see the Unix
system calls (perhaps you were debugging the Unix emulator). 

-----Original Message-----
From: Jonathan S. Shapiro [mailto:jsshapiro@earthlink.net]
Sent: Sunday, April 26, 1998 4:00 AM
To: eros-arch@eros.cis.upenn.edu
Subject: debugger v. domain keeper


There is a tension between the debugger and the domain (process)
keeper that I am not happy with.

In general, it is not possible for a debugger to know which faults are
recoverable and which should be considered debugging events.  For one
process, a floating point fault may be normal and emulatable, while
for another process it is an error because the process is not supposed
to use floating point.  This knowledge is presently built into the
domain keeper.

Recoverable faults may be thought of as extending the virtual machine,
in the sense that the domain keeper provides externally defined
semantics for operations that the virtual machine considered
exceptional.

At the moment, the debugger cannot simply get in the middle and spoof
the domain keeper by passing the fault through to see what happens.
This is because the domain keeper may take actions such as putting the
process on a "faulted" list, which should not be done if the fault has
been handed to the keeper on a "trial run" basis.

Presently, the current EROS domain keeper will always receive:

	#define OC_FAULT      0

as the order code when invoked by the kernel.  I propose to introduce
(by convention) a new order code:

	#define OC_TRIALFAULT	xxx

This order code is intended for use by debuggers, and indicates that
the keeper should not persue any fatality metapolicy it may contain.

Does this seem reasonable?  Is there a better solution?


shap