All of lore.kernel.org
 help / color / mirror / Atom feed
* [parisc-linux] subo -> overflow_trap (12) -> What to do?
@ 2002-08-17 22:05 Carlos O'Donell
  2002-08-20 11:49 ` [parisc-linux] mcontext registers on parisc64 (was Re: subo -> overflow_trap (12) -> What to do?) Christophe Rhodes
  0 siblings, 1 reply; 3+ messages in thread
From: Carlos O'Donell @ 2002-08-17 22:05 UTC (permalink / raw)
  To: parisc-linux; +Cc: csr21

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

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'


[-- Attachment #2: kernel-parisc-trap.c.diff --]
[-- Type: text/plain, Size: 747 bytes --]

--- linux/arch/parisc/kernel/traps.c.orig       2002-08-17 17:37:26.000000000 -0400
+++ linux/arch/parisc/kernel/traps.c    2002-08-17 17:58:39.000000000 -0400
@@ -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 */


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [parisc-linux] mcontext registers on parisc64 (was Re: subo -> overflow_trap (12) -> What to do?)
  2002-08-17 22:05 [parisc-linux] subo -> overflow_trap (12) -> What to do? Carlos O'Donell
@ 2002-08-20 11:49 ` Christophe Rhodes
  2002-08-20 13:22   ` [parisc-linux] mcontext registers on parisc64 Carlos O'Donell
  0 siblings, 1 reply; 3+ messages in thread
From: Christophe Rhodes @ 2002-08-20 11:49 UTC (permalink / raw)
  To: Carlos O'Donell, parisc-linux

[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

On Sat, Aug 17, 2002 at 06:05:45PM -0400, Carlos O'Donell wrote:
> 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 :)

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)

[-- Attachment #2: test.c --]
[-- Type: text/x-csrc, Size: 707 bytes --]

#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;
}

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [parisc-linux] mcontext registers on parisc64
  2002-08-20 11:49 ` [parisc-linux] mcontext registers on parisc64 (was Re: subo -> overflow_trap (12) -> What to do?) Christophe Rhodes
@ 2002-08-20 13:22   ` Carlos O'Donell
  0 siblings, 0 replies; 3+ messages in thread
From: Carlos O'Donell @ 2002-08-20 13:22 UTC (permalink / raw)
  To: Christophe Rhodes; +Cc: parisc-linux

> 
> 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

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-08-20 13:24 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-08-17 22:05 [parisc-linux] subo -> overflow_trap (12) -> What to do? Carlos O'Donell
2002-08-20 11:49 ` [parisc-linux] mcontext registers on parisc64 (was Re: subo -> overflow_trap (12) -> What to do?) Christophe Rhodes
2002-08-20 13:22   ` [parisc-linux] mcontext registers on parisc64 Carlos O'Donell

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.