Re: bounds checking and traps

[Zack Weinberg <zack at codesourcery dot com>]

"Jan Beulich" <JBeulich@novell.com> writes:

>>Yah, and (this is what I'm saying, this is what I'm telling you) they
>>*all* define int #5 to have the same effect as #BR trap.  Go on,
> prove
>>me wrong.
>
> Easily done: Win2K raises a GP fault on INT 05, but Bounds Range
> Exceeded on a failed bound.

I should have been more specific about what I meant by 'same effect'.

GCC expects that the "trap" insn will unconditionally cause a hardware
fault which (unless the program takes action to intercept it) will
terminate the process.  Which hardware fault it is doesn't matter -
you found the __builtin_trap expander, so you'll note that the action
when there's no machine-specific "trap" defined is to synthesize a
call to abort().  To quote the not-very-good documentation:

  @cindex @code{trap} instruction pattern
  @item @samp{trap}
  This pattern, if defined, signals an error, typically by causing
  some kind of signal to be raised.  Among other places, it is used by
  the Java front end to signal `invalid array index' exceptions.

The commentary in i386.md says "in honor of the too-inflexible-for-BPs
'bound' instruction, we use interrupt 5" ... but that's just an
explanation for why _that_ software interrupt vector was picked.  Any
vector number that can be counted on to terminate the invoking process
will do.  It's been proposed to use INTO (trap on signed overflow) as
an ersatz conditional-trap instruction, for instance.  Unless your
system doesn't unconditionally terminate the process on int #5,
there's no need to mess with i386.md.

As the doc quote suggests, this does interact with the Java runtime,
but only up to a point: the Java runtime for Unixy systems expects
that a bounds-check fault (which is implemented with a "trap"
instruction) causes delivery of SIGSEGV or (on some systems) SIGBUS,
not for example SIGILL.  This is why we don't use "hlt" or "ud2".
If system does something other than SIGSEGV on int #5, and you want
the Java runtime to work, then you can fix that in the Java runtime,
which is already amply prepared to cope with weird system mechanisms
for reporting bounds-check faults.

zw