subo -> overflow_trap (12) -> What to do?

pa,

Talking with Christophe Rhodes who is porting some Common Lisp code[1] to parisc-linux and he has some old-ish code from HPUX (circa 1994) that does some interesting things :)

The code does a 'subo' and it _does_ cause an overflow_trap (12) which is currently unhandled in our traps.c ... this trickles into a SIGBUS, which is questionable (as the comment notes).

In HPUX the code sets si_code to FPE_INTOVF as well as sending a SIGFPE to the offending application. From there the handler does all the 'bignum' cleanup and Lisp land is all happy.

So I've gone ahead and implemented this functionality into traps.c, but I'm not sure if this is the right way to go. What do people think? If any HPUX people would like to chime in? :)

Patch attached.

c.

[1] Package is 'sbcl'

@@ -561,6 +561,14 @@
                force_sig_info(SIGILL, &si, current);
                return;
 
+       case 12:
+               /* Overflow Trap, let the userland signal handler do the cleanup */
+               si.si_signo = SIGFPE;
+               si.si_code = FPE_INTOVF;
+               si.si_addr = (void *) regs->iaoq[0];
+               force_sig_info(SIGFPE, &si, current);
+               return;
+
        case 14:
                /* Assist Exception Trap, i.e. floating point exception. */
                die_if_kernel("Floating point exception", regs, 0); /* quiet */

Firstly, thanks to this, my code seems to work on a parisc-1.1 machine that I have available. However, I'm having trouble getting it to run on a parisc64 kernel...

As you may have gathered, the Common Lisp compiler in question depends quite heavily on signal handling, and in particular SA_SIGINFO sigaction-style handling. This seems to work fine in 32-bit mode, but not in 64-bits; in particular, there seem to be some 32/64-bit confusions going on...

I've attached a test program to (try to) demonstrate the problem; it's complicated a bit by Debian bug #157374 (basically, incompatibility between <sys/ucontext.h> and what the kernel actually delivers) but I hope that what it's doing is clear enough... if I'm doing something wrong, please let me know.

Inspecting the sigcontext that I get on a parisc64 machine gives register contents looking a bit like

    [...]
    0xffffffff, 0xdeadbeef, 0x0, 0xf00d, 0x0, 0xfaf00380, 0x0, 0x2097a, 0x0, 
    0xfaf001a4, 0x0, 0x2096a, 0x0, 0x1, 0x0, 0x20972, 0x0, 0x1, 0x0, 0x0, 0x0, 
    [...]

and the alternation of data, 0/-1 is what leads me to believe that 64-bit quantities are being delivered; userland only seems to know about 32-bits, though.

Please don't hesitate to get back to me with comments and/or criticisms,

Cheers,

Christophe

Jesus College, Cambridge, CB5 8BL                           +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/                  (defun pling-dollar 
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)

#include <stdio.h>
#include <sys/ucontext.h>
#include <signal.h>
/* c.f. Debian Bug#157374 */
#include <asm/sigcontext.h>

void sigsegv_handler(int signal, siginfo_t *info, void *context) {
fprintf(stderr, "si_addr: %p (should probably be 0x0 [aka \"(nil)\"]\n",info->si_addr);
fprintf(stderr, "%r1 : 0x%08x (should probably be 0xdeadbeef)\n",

	  ((struct sigcontext *) &(((ucontext_t *) context)->uc_mcontext))->sc_gr[1]);

exit(0);
}

int main () {
int *foo;
struct sigaction sa;

  sa.sa_sigaction = sigsegv_handler;
  sa.sa_flags = SA_SIGINFO | SA_RESTART;
  sigaction(SIGSEGV, &sa, NULL);

asm("ldil L%0xdeadbeef,%r1");
asm("ldo R%0xdeadbeef(%r1),%r1");
foo = NULL;
*foo = 3;
}

This might be a kernel bug. We should always return 32-bit quantities to userspace (until we get a 64-bit userspace :).

Once we straighten out the sigcontext->mcontext_t issue in glibc, we can take a look at this. I might just patch glibc on my box tonight... and go forward with hacking on the kernel bits.

c.