On Mon, 30 Jul 2001, Kevin D. Kissell wrote:
> Many years ago, I went to a lot of effort to see to it that
> FP exceptions on the Fairchild Clipper passed enough
> information up through SIGFPE to allow full userland
> emulation or fixup and replay-on-return of the operation
> on floating point faults (entertaining because there was
> a seperate FP PC). And of course no one ever used it! ;-)
That's why I took the KISS approach. Current code is cheap and satisfies
the specs I use, i.e. glibc's info pages. If anyone needs anything more
one is free to improve handlers.
> I missed the beginning of this thread, but it looks from the
> patch as if this is really about handling integer overflow
> exceptions, not FP exceptions. That's unfortunate.
The patch is about break and trap instruction handlers, indeed.
> To begin with you are correct in that we should be
> passing the EPC value at the exception (and certainly not
> the result of invoking compute_return_epc(), much less
> its side effects!), and the state of the BD bit from the
> Cause register, either abstracted into a variable in the
> info structure or as a flat-out copy of the Cause register.
I don't think passing BD is needed here. Enough information is
available. A SIGFPE due to a branch or a jump instruction is impossible.
Unless you have a chip on fire, in which case problems with signal
handlers are insignificant.
> I would recommend the former as being less of a security
> hole. Yes, we could blow that off and make the user
> decode for branches himself, but it's tacky. But what's
> more pernicious is the fact that, being an integer exception,
> it could have resulted from an overflow of any of the GPRs,
> including those that will be used by the low-level library
> code dispatching the signal to the user, and in the generated
> code of the user's own signal handler. If we actually want
> to allow the user to fix the operation and saturate (or whatever)
> the destination register, enough of the trap context needs
> to be passed up to the signal handler *and* back down
> on the signal return to allow that manipulation, followed
> by a resumption of execution at the instruction following
> the one that generated the trap.
Let's just leave it as an excercise to one writing some emulation code.
A general-purpose handler in the kernel or libc (which no one will
probably use) is an overkill and by defining own strict coding rules (be
it a calling convention, shadow registers or whatever) one can create
software that suits one's specific needs.
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: email@example.com, PGP key available +