Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Dec 1997 00:05:58 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        bde@zeta.org.au, reilly@zeta.org.au
Cc:        freebsd-current@freebsd.org, rcarter@consys.com
Subject:   Re: xlock: caught signal 8 while running galaxy mode.
Message-ID:  <199712151305.AAA29915@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712151305.AAA29915>