Re: [B2-devel] Re: New SIGSEGV code to be committed

[Brian J. <bjj...@us...>]

--- Gwenole Beauchesne <gb...@di...> wrote:
> 
> > The new code seems to work fine on IRIX, just like the old code did.
> 
> Is your SGI box using siginfo_t or a sigcontext subterfuge ?
> [Look at your config.h for the appropriate #define]

(Sorry it's taken so long for me to get back to you on this.)

#define HAVE_SIGINFO_T 1
/* #undef HAVE_SIGCONTEXT_SUBTERFUGE */


> > At least in 68030 mode.  Whenever I try to use 68030+FPU or 68040,
> > I get all kinds of nasty FP bugs, usually including wild
> > references and core dumps.  See bug 422776.  Is this a known
> > problem with the UAE FPU core on big endian or non-x68 systems?
> > I'm using MacOS 7.5.5.
> 
> What do you mean with wild references ?
> 
> When the FPE is enabled, do you get core dumps because the sigsegv
> handler fail to handle the faultive address or do you get some
> SIGBUS error because of possible mis-aligned accesses in the FPE
> code ?

Here's what I got on a recent CVS build.  Using 68030+FPU, direct
addressing, I started up the calculator and entered 4 / 3.  When I
typed the 3, B2 core dumped with a SIGBUS:

bjjsgi> dbx BasiliskII core
dbx version 7.3.2 73509_May21 MR May 21 2001 17:15:31
Core from signal SIGBUS: Bus error
(dbx) where
>  0 ::do_get_mem_word(0x84c9c000, 0xf72a62, 0x5c0ea5e, 0x0, 0x5c0e926, 0x4, 0xf7291a, 0x10107b28) ["/d3/BasiliskII2/BasiliskII/src/sony.cpp":40, 0x100c0fb0]
   1 ::m68k_run_1(void)(0x84c9c000, 0xf72a62, 0x5c0ea5e, 0x0, 0x10107b44, 0x6c74, 0x10107b30, 0x4edb82e) ["/d3/BasiliskII2/BasiliskII/src/sony.cpp":1223, 0x100374e0]
   2 ::m68k_go(int)(0x84c9c000, 0xf72a62, 0x5c0ea5e, 0x0, 0x10107b44, 0x6c74, 0x10107b30, 0x4edb82e) ["/d3/BasiliskII2/BasiliskII/src/sony.cpp":1253, 0x100c0ef8]
   3 ::main(0x1, 0x7fff2ec4, 0x5c0ea5e, 0x0, 0x10107b44, 0x6c74, 0x10107b30, 0x4edb82e) ["/d3/BasiliskII2/BasiliskII/src/main.cpp":558, 0x100d3758]
   4 __start() ["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177, 0x10033f48]
(dbx) $pc-16/8i
 [::m68k_reset(void):1078, 0x100c0fa0]  jr      ra
 [::m68k_reset(void):173, 0x100c0fa4]   sw      at,-6260(gp)
 [???, 0x100c0fa8]      nop
 [???, 0x100c0fac]      nop
*[::do_get_mem_word:40, 0x100c0fb0]     lbu     v1,0(a0)
 [::do_get_mem_word:40, 0x100c0fb4]     lbu     v0,1(a0)
 [::do_get_mem_word:40, 0x100c0fb8]     sll     v1,v1,8
 [::do_get_mem_word:40, 0x100c0fbc]     jr      ra
 [::do_get_mem_word:40, 0x100c0fc0]     or      v0,v0,v1
r0/zero=0x0     r1/at=0xf72a66
r2/v0=0xffffffff80000000        r3/v1=0x4e00
r4/a0=0xffffffff84c9c000        r5/a1=0xf72a62
r6/a2=0x5c0ea5e r7/a3=0x0
r8/a4=0x5c0e926 r9/a5=0x4
r10/a6=0xf7291a r11/a7=0x10107b28
r12/t0=0x10107b44       r13/t1=0x6c74
r14/t2=0x10107b30       r15/t3=0x4edb82e
r16/s0=0x1      r17/s1=0x7fff2ec4
r18/s2=0x7fff2ecc       r19/s3=0x7fff2fc8
r20/s4=0x0      r21/s5=0x0
r22/s6=0x0      r23/s7=0x101103e8
r24/t8=0xf72926 r25/t9=0x1007d7c0
r26/k0=0x0      r27/k1=0x50087e72a
r28/gp=0x1010f570       r29/sp=0x7fff2c10
r30/s8/fp=0x0   r31/ra=0x100374e8

mdlo=0x1e       mdhi=0x2
cause=0x10      pc=0x100c0fb0
fpcsr=0x41800004        sr=0x0
badvaddr=0x84c9c000     fpeir=0x0

Looks like it tried to load from a bad Mac PC value.  It's suspicious
that v0 (the return value from a recent subroutine) is
0xffffffff80000000... sign extension problem?


> BTW, do MIPS processors support 128-bit FP precision ?

No.  Just single- (32-bit) and double-precision (64-bit) IEEE.

> > (Although the new code does change the symptoms of the problem a
> > bit:  now direct addressing core dumps (with an appropriate
> > message from the segv handler) and real mode hangs Speedometer.)
> 
> Could you tell me the address reported by the segv handler and the
> MEMBaseDiff offset value ?

I'm having trouble tracking it down...   perhaps it got optimized
away.

> I used to get a crash in real mode with Speedometer under Linux/x86.
> Probably the patch I added in rom_patches.cpp make it hang on a
> big-endian system ?
> 
> Can you disable the patch and tell me if it crashes for you too ?
> [Search for "Speedometer" in rom_patches.cpp]

That looks like it only applies to real addressing.  This latest crash
happened with direct addressing.

						Brian

--------------------------------------------------------------------

   "My bicycle is an elegant form of transportation.  It carries me far
    faster than I can run, yet I can carry it with one hand."
                                           -- me