Changes between Initial Version and Version 1 of Internals/ExceptionHandling

May 11, 2009, 8:11:21 AM (11 years ago)



  • Internals/ExceptionHandling

    v1 v1  
     1= Exception handling =
     2The manual has some information on this. Here's some more.
     4== UUOs (by gb) ==
     6=== Origin ===
     7On the DEC PDP-10, the acronym UUO stood for "Unimplemented User Operation"; UUOs were used to invoke system services and/or to invoke what we'd think of as exception handlers. [...] As it's used in CCL, the term just means "an illegal instruction that'll ultimately cause a lisp-aware handler function to be called."
     9=== Implementation details ===
     10Executing an "int $n" (#xcd n) instruction transfers control to an
     11entry insome (incredibly complex and baroque) table of handlers
     12maintained by the chip.  The OS might use a few entries in this table
     13to implement system calls (though modern x86 CPUs often have faster
     14ways of doing system calls), and some entries are reserved for hardware-
     15related interrupts.
     17Trying to execute an "int $n" instruction that doesn't have a defined
     18entry in this table causes a General Protection Fault, and this
     19eventually causes (on Unix) a signal to be raised.  Exactly what
     20signal depends on the OS; there's a macro called SIGNUM_FOR_INTN_TRAP
     21defined conditionally in ccl/lisp-kernel/x86-exceptions.h that defines
     22this.  As you can see, it's generally overloaded on SIGBUS or SIGSEGV,
     23which usually indicates an addressing exception (yes, SIGILL would
     24make more sense, but since it involves a GP fault an undefined "int
     25$n" winds up taking the same path as a memory protection fault) and
     26we need to look at other arguments to the signal handler (as defined
     27by the IS_MAYBE_INT_TRAP macro: if IS_MAYBE_INT_TRAP is true, we believe
     28that we can look at the the byte that the PC in the signal context is
     29pointing to to see if it's #xcd; if not, the SIGSEGV or SIGBUS might
     30have been caused by trying to execute code at an unmapped address.)
     32We also use "ud2a" instructions (followed by a byte or more of data)
     33for similar purposes, but "int $n" is generally shorter; illegal
     34instructions that use the ud2a opcode (which generally -does- raise
     35SIGILL when executed) are sometimes called "xuuos" (eXtended UUOs).
     37Once in a while (when doing a port to a new OS), we've found that the
     38OS uses an interrupt that we've previously considered free for our
     39use, and have had to do things differently (reassign UUOs or avoid
     40emitting conflicting ones.)  I suppose that that could happen if we
     41ported to some other OS (NetBSD ?), but it's unlikely that x8632 OSes
     42will invoke new functionality via "int $n" (since other means of doing
     43system calls are generally faster/better.)  See the comment in x86-asm.lisp:
     45{{{;;; DON'T use #xcd8x: doing so will make Mach angry and confused.}}}