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: macro@ds2.pg.gda.pl, PGP key available +
