From owner-freebsd-current Mon Dec 15 05:15:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA26122 for current-outgoing; Mon, 15 Dec 1997 05:15:43 -0800 (PST) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA26113 for ; Mon, 15 Dec 1997 05:15:34 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id AAA29915; Tue, 16 Dec 1997 00:05:58 +1100 Date: Tue, 16 Dec 1997 00:05:58 +1100 From: Bruce Evans Message-Id: <199712151305.AAA29915@godzilla.zeta.org.au> To: bde@zeta.org.au, reilly@zeta.org.au Subject: Re: xlock: caught signal 8 while running galaxy mode. Cc: freebsd-current@freebsd.org, rcarter@consys.com Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >What I'm not sure about is figuring out, from the gdb output, where >things have gone awry. > >(gdb) run -S call.lst >Starting program: /usr/home/andrew/work/Clients/Syrinx/jun-19/sycon/unix/try/syph_ux -S call.lst >Call Setup. >RunUtterance(model:amt4.bin, speech:amt1.lin) > >Program received signal SIGFPE, Arithmetic exception. >0x4a8c in CalcU () at state.c:305 >305 if (s > *pMax) *pMax = s; >(gdb) info float >u: status 0xb9aa: exceptions: DENORM OVERF LOS; flags: 0001; top 7 >e: status 0x3900: flags: 0001; top 7 >control 0x1272: compute to 53 bits; round NEAREST; mask: DENORM UNDERF LOS; >last instruction: opcode 0x1d0; pc 0x8:0xf01847b2; operand 0x10:0x0 0x0:0xf01847b2 is in the kernel. I think this uncommitted fix of mine may actually matter: diff -c2 npx.c~ npx.c *** npx.c~ Wed Nov 19 03:45:54 1997 --- npx.c Wed Nov 19 03:46:08 1997 *************** *** 1,2 **** --- 1,3 ---- + static volatile int old_npxintr_compat = 1; /*- * Copyright (c) 1990 William Jolitz. *************** *** 518,524 **** outb(0xf0, 0); ! fnstsw(&curpcb->pcb_savefpu.sv_ex_sw); ! fnclex(); ! fnop(); /* --- 524,539 ---- outb(0xf0, 0); ! /* ! * Save state to work around the IRQ13 interface bugs. If the ! * exception 16 interface is used then the exception-pending bits ! * will be saved and will cause another exception on the next FPU ! * instruction in user mode (the same one unless the exception is ! * cleared by the application). If the IRQ13 interface is used ! * then the exception-pending bits will be saved and will usually ! * a bogus IRQ13 in the kernel when the state is restored. ! */ ! npxsave(&curpcb->pcb_savefpu); ! if (old_npxintr_compat) ! curpcb->pcb_savefpu.sv_env.en_sw &= ~0x80bf; /* The fnop() in the original version is supposed to flush out any pending IRQ13's on old braindamaged systems, but sicne it is down in process context (the process's registers haven't been saved in pcb_savefpu), it corrupts the pointer to the last FPU instruction (all non-control FPU instructions set this pointer; fnclex and fnsave are control instructions but fnop isn't). Just deleting the fnop() should fix it too. Don't clear `old_npxintr_compat'. Clearing it makes ignoring SIGFPE even more broken than usual (the SIGFPE is repeated endlessly). >If the problem really is overflow, then the exceptions are doing the >right thing, and have caught a bug that I want to know about, but can >you tell from the above where I should be looking? It's certainly overflow. Fix the kernel bug to find where it occurs. >> `p' can't handle variables in x87 registers. It prints the above value >> after `register float z; z = 1' here. I think it just doesn't know >> where the variables really are. Use `info float' to get more information. > >Thinking about it, it would be quite hard for a debugger to know that >about register floats on a stack: they move around all the time. Would >it be possible to force the compiler to ignore "register" on floats >when the "-g" flag is used? -g is supposed not to affect the code. Debugging formats have complications to keep track of when variables are in registers, but the i387 registers aren't handled well. I think movement of the stack top doesn't cause many extra complications - keeping a variable in the same i387 register for long is rarely possible, and it should be just as easy to record keeping of a variable in a different register as it is to record keeping of it in a register instead of memory. Bruce