* With this workaround, it's impossible for the kernel to distinguish
whether exceptions 0-2 and 6 occured due to an INT ${0-2,6}
instruction or due to their normal causes. Without the workaround, an
INT ${0-2,6} instruction would normally cause a protection fault, in
turn causing the process to get a SIGBUS, because the descriptors for
these exceptions are marked as not being callable by user code.
Instead the process will get a SIGFPE, SIGTRAP, SIGBUS, or SIGILL,
depending on which of INT ${0-2,6} was executed.
* There's also no way to distinguish whether we got exceptions 3-4 due
to an INT3 or INTO instruction, or due to an INT ${3-4} instruction,
without actually inspecting the user code. Ideally, we want to know
this so we can advance the PC the right amount; the page fault is a
restartable exception, and the saved PC points to the {INT3,INTO,INT
$N} instruction, whereas these instructions normally cause the
exception to be taken after the PC has been advanced. Currently I
just patch the PC as if the exception always occured due to INT3 or
INTO, since no real code uses INT ${3-4}, or uses a prefix on them,
and I'd rather not slow down this path much more to check.
* The previous also applies to the exception 5 and the BOUND
instruction, which I haven't fully dealt with as of this writing. (It
actually uses the operand size prefix, so it needs to be decoded.
YUCK.)
Note that since VM86 mode always traps INT instructions via a GP
fault, code running in VM86 mode is unaffected by this. In the all
too likely event that some whacked out DOS program actually uses INT
${0-6}, its behaviour inside doscmd or dosemu should not change.