View Single Post
Old 25 September 2015, 17:49   #45
FS-UAE Developer

FrodeSolheim's Avatar
Join Date: Dec 2011
Location: Førde, Norway
Age: 38
Posts: 3,561
Originally Posted by jbl007 View Post
But I'm curious... Was it the change that caused the crash in the 64bit version?
Accuracy must have been fixed by earlier fixes. The latest crash issue (FSINH) was more or less to guaranteed to crash every time (and therefore it cannot have caused accuracy problems )

Originally Posted by jbl007 View Post
JIT: Fault address is 0x7c295bea at PC=0x423817ac
JIT: Can't handle access PC=0x423817ac!
JIT: Instruction bytes 67 45 8a a3 00 00 00 50 67 44
Thank you, this is exactly what I need. I can actually tell from this output (with almost certainty) what the problem is. If we punch the instruction bytes into a disassembler we get:
67 45 8a a3 00 00 00    mov r12b,BYTE PTR [r11d+0x50000000]
i.e. move a byte to (the lower 8 bits of the x86-64) register r12 from memory location 0x50000000 + the 32-bit value in register r11(d). 0x50000000 is the start of the Amiga address space in FS-UAE virtual (native) memory.

FS-UAE crashes because there isn't anything at location 0x7c295bea. We can easily calculate the (Amiga) address the demo tries to access:
0x7c295bea - 0x50000000 = 0x2c295bea
So 0x2c295bea is the content of the r11d register and the demo tries to read one byte from (Amiga address) 2C295BEA. You can also verify with the "Memory map after autoconfig" in FS-UAE.log.txt that there isn't any memory bank at this address.

On a real hardware, nothing will crash (by itself) when the demo reads from non-existing memory. -And in FS-UAE, normally, this should be handled by the access fault handler. The problem (and the cause of the crash) is that the access handler does not understand this *specific* x86-64 instruction, and thus cannot figure out how to handle it.

The fix is to extend the instruction decoder in the access fault handler to understand mov instructions related to all the (new) x86-64 registers (It would have worked if JIT had chosen one of the original x86 registers instead of a "new" x86-64 register). I'll probably borrow some code from the ARAnyM project, as it looks like they have implemented a much more complete instruction decoder for x86-64

But with this knowledge, we can also speculate about a couple of workarounds (both should work) until I have fixed the instruction decoder:

1. Make sure valid memory is available in this location. For example, to make sure we have Zorro III memory from 0x10000000 to 0x30000000 (containing the location 0x2c295bea):
zorro-iii-memory = 512M
uae-z3mapping = uae
2. Use indirect memory access instead of direct

(Don't worry, I will not write an "essay" for every new discovered problem )

Anyway, thanks, this will be a good use for testing the new instruction decoder once I've implemented it!

Last edited by FrodeSolheim; 26 September 2015 at 15:16.
FrodeSolheim is offline  
Page generated in 0.04257 seconds with 11 queries