1

Taken from the Intel 80386 Programmer's Reference Manual, CH9:

Exceptions are classified as faults, traps, or aborts depending on the way they are reported and whether restart of the instruction that caused the exception is supported.

Aborts: An abort is an exception that permits neither precise location of the instruction causing the exception nor restart of the program that caused the exception. Aborts are used to report severe errors, such as hardware errors and inconsistent or illegal values in system tables.

(Emphasis mine)

What does it exactly mean that aborts are exceptions that do not permit precise location of the instruction causing the exception?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Tortellini Teusday
  • 1,335
  • 1
  • 12
  • 21
  • 1
    I'd assume it means that the exception address isn't guaranteed to be meaningful, and/or that some side-effect of a later instruction might be visible, breaking the illusion of running instructions one at a time in program order. (Or perhaps an older instruction isn't fully completed. Or since actual 386 was an in-order CPU that isn't pipelined except for instruction fetch, I think, maybe part of the *current* instruction, could be partially done, like a FLAGS update but result not stored yet, if your ECC RAM fails in the middle of `adc [mem], reg`?.) – Peter Cordes Jul 12 '21 at 15:46

1 Answers1

4

There's only 2 "abort" exceptions:

a) Double fault exception. This happens when trying to start one exception caused a second exception; where the instruction pointer (saved by CPU when starting the double fault exception handler) could be from the original instruction, the first exception, the second, something else or nothing. In this case, because the CPU couldn't start the first or second exception handler you can't return from the double fault to the second (or first) exception handler anyway.

b) Machine check exception. This is purely for hardware faults where you probably don't want to assume that memory, or caches, or the CPU actually work. You can't expect "guaranteed behavior" from faulty hardware.

Note 1: Technically, for some causes of machine check, you can return to the precise location of whatever happened to be interrupted by the exception; you just need to be very careful about determining if you can/can't return (and need some way to fix/work-around the hardware problem/s so that returning from the machine check exception handler won't just trigger a second machine check exception).

Note 2: It's perfectly possible for the exceptions preceding a double fault, or machine check, to be caused by something that isn't an instruction at all (e.g. caused by an IRQ). In these cases "the precise location of the instruction causing the exception" would be "the precise location of something that doesn't exist". Intel's words should be interpreted as being conditional (like "an exception that permits neither precise location of the instruction causing the exception if there is one, nor restart of the program that caused the exception if there is one").

Brendan
  • 35,656
  • 2
  • 39
  • 66