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

[<gb...@di...>]

Hi,

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

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

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

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

Actually, I no longer get any crash in real mode under Linux/x86 because
the system could map the entire Mac RAM and ROM from 0, i.e. not only
0x2000 bytes for the LowMem globals.

Bye,
Gwenol=E9.