Re: [hatari-devel] Re: natfeats detection issue

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

Douglas, aren't you using a really old version of Hatari (1.7.x)?

The latest Mercurial version of WinUAE CPU core has a lot of fixes, also to 
exception handling.  You might want to try that before investigating 
further.


	- Eero

On sunnuntai 01 maaliskuu 2015, Eero Tamminen wrote:
> 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