View Single Post
Old 24 September 2015, 18:50   #34
FS-UAE Developer

FrodeSolheim's Avatar
Join Date: Dec 2011
Location: Førde, Norway
Age: 40
Posts: 3,755
@jbl007 Thank you, it worked fine (= it crashed )

I have identified and fixed the crash. The problem was manipulation of the stack pointer (ESP) in raw_fsinh_rr. The code must the full 64-bit RSP register for x86-64, or else very bad things will happen (and it did). It crashes because the stack pointer gets corrupted. I will push a commit shortly.

Regarding debugging, it is of course great that you all want to give helpful advice, but it often comes down to reading the generated x86(-64) instructions (and FS-UAE JIT source code) and figure out what is needed to make it work on x86-64. This requires knowledge about the JIT compiler and familiarity with x86(-64) assembly, and is not a particular easy task

You will not be able to get a stack trace in the debugger, because the crashes almost always happens in JIT-generated code, which is just one large 8 MB (typically) segment with generated code (no regular C functions here). In this particular crash, it was even worse, because when the stack is corrupted, more stupid things starts to happen, and the crash is often unrelated to the actual stack corruption.

The most common (crash) occurrence with the x86-64 JIT compiler is that an instruction causes a read or write to an invalid memory location. When this happens, the segfault handler in FS-UAE logs the failing instruction bytes to the log file just before it "allows" the crash to proceed. Disassembling these instruction bytes is usually the first step in figuring out the crash. The next step is usually to enable a debugging feature in FS-UAE where disassembled JIT-generated code is logged every time a new block is compiled (#define USE_UDIS86). The crash is usually caused by an error in the last compiled block before the crash.

To summarize, the best way you can help me - for now - is to find reproducible problems (and help me reproduce them)

Btw, the problem with raw_fsinh_rr isn't unique to that function. I see similar code in a few other functions which needs similar treatment. I can easily fix these functions as well, but right now I don't have test cases to verify that the fixes are correct. So, if any of you is comfortable writing m68k Amiga programs (assembly, using FPU functions), I can create a list of a few FPU functions I would like a test program for...

Last edited by FrodeSolheim; 24 September 2015 at 19:20.
FrodeSolheim is offline  
Page generated in 0.07224 seconds with 11 queries