[hatari-devel] Re: natfeats detection issue

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On perjantai 27 helmikuu 2015, Douglas Little wrote:
> I think there may be a problem in the natfeats detection code I was using
> in BadMooD and now in Q2.
> 
> I noticed that depending on where I placed my DSP code in the binary, it
> was becoming corrupted and failing to boot. I was able to prove this with
> a CRC.
> 
> I narrowed the CRC failure to immediately after the natfeats detection
> call. In other words, the CRC passes before the call, and fails after it.

Does the issue happen with NatFeats enabled, disabled, or both?


> Inspecting the natfeats code, I saw 2 slightly suspicious things.
> 
> 1) The assembly routine _detect_nf is called directly from C, but it
> preserves no registers. This one is probably ok since the 68k code uses
> only d0,a0,a1

Doesn't GCC (and all C-compilers on m68k) treat d0/d1/a0/a1 as scratch 
registers when calling extern functions (regardless of whether they're 
implemented in assembly or C)?

Detection code is copied from EmuTOS which I would assume to get it right, 
and EmuTOS is compiled with GCC.


> but I wasn't sure if something deeper could change other
> registers on the way back (emulator).

With NatFeats enabled, emulator shouldn't change anything else besides d0.


> 2) If detect_nf fails, it will trigger the illegal instruction exception
> ($10), which is just pointing at the end of the function. While it does
> restore the $10 vector before returning, it is actually still executing
> in the exception state, with a big stackframe waiting to be processed.
> It gets around this by restoring the stack pointer directly.
> 
> One other details is the fact I removed the supervisor/user switch that
> was originally book-ending the detect_nf() call:
> 
> //    dml: we're already in super mode
> //    void *sup = Super(0);
>     nf_ok = detect_nf();
> //    Super(sup);
> 
> I still don't understand what is directly causing the corruption so I'm
> still looking into that. Could it be that the emulator is writing to ST
> ram while performing the natfeats operations behind the scenes?

Only at the request of the emulated code.


> I'll see if I can locate the affected bytes and breakpoint them.
> 
> Now that I know the nf_init is causing a problem I can probably work
> around it but perhaps you have some clues as to what could be happening
> here?

No, but you could set breakpoints just before and after NatFeats detection 
and enable profiling.  Profiling will show you all code that gets executed, 
so you see if there's some unexpected code being executed.


	- Eero