> It occurs to me that there may be another way to solve this -- [...]

An addendum to the previous:

Not quite all entries into the page fault handler will be due to user
instructions.  In particular, our partially mapped IDT may cause a
page fault during a normal trace trap.  This should not be reexcuted;
if we do so, we'll skip an instruction, which would screw the
debugger.  We should be able to differentiate this condition by
checking for the RF flag; if it's not set, then the trap wasn't due to
a particular instruction, and we should emulate it per the BSDI code.

Using the RF flag, though, we could also fix the BSDI hack to not have
the original caveats.  If RF is set, we know that a particular
instruction caused the fault, and we can always decode it to decide
what to do:

* If the page fault was for vectors 3-5, advance the PC past the
instruction, turn off the RF flag, and enter the fault handler for the
real exception.

* If the page fault was for vectors 0-2 or 6, and the instruction was
not INT, don't advance the PC, and enter the fault handler for the
real exception.

* If the page fault was for vectors 0-2 or 6, and the instruction was
INT, don't advance the PC, and enter the privileged instruction
handler.

(Change the above rules as appropriate if you care about what happens
with the undocumented INT01 instruction.)

[And now I'm really going to go sleep.  B-)]