Re: [hatari-devel] 030 exceptions on auto-increment instructions

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 2/24/20 12:45 PM, Nicolas Pomarède wrote:
> Le 13/04/2019 à 01:08, Eero Tamminen a écrit :
> > While mailing about some issue I was hitting with m68k Linux, it
> > was noticed that Linux fault handler gives different register
> > values under Hatari than under real 030.
> >
> > Faulting instruction is:
> >      $00249f5a : 0e98 2000  moves.l   (a0)+,d2
> >
> > A0 reg content is struct member offset address, but struct was NULL.
> >
> > Under Hatari Falcon emulation, Linux fault handler reg dump showed A0
> > value to be 0x04, whereas with under real 030 Mac it showed 0x08.
> >
> > Environments weren't completely identical, so it's not 100% sure
> > this is WinAUE CPU core issue, but I think it warrants checking.
> >
> >
> > If you can have recent Linux version (5.x or slightly older, with
> > SYSRQ config option enabled) under WinUAE and real m68k HW, this
> > is easy to trigger.  Just do:
> >      # echo t > /proc/sysrq-trigger
>
> regarding this issue, as of 2020/02/23 Hatari includes all the latest 
> changes from WinUAE's cpu core where many of these stack values were 
> measured on real HW and are now emulated.
>
> Can you check if this works better ?

I haven't checked autoincrement addresses yet,
but same things that were crashing earlier are
still crashing.

However, kernel backtraces look a bit different now:
-----------------------------------------
*** ILLEGAL INSTRUCTION ***   FORMAT=0
Current process id is 37
BAD KERNEL TRAP: 00000000
PC: [<0013035a>] strncpy_from_user+0x62/0xec
SR: 2200  SP: 4512139a  a2: 008545b0
d0: 00000000    d1: 2f737973    d2: 00000ff0    d3: 00000ff0
d4: 00000ff0    d5: 00000000    a0: 009b3010    a1: 80155c8c
Process cttyhack (pid: 37, task=f9793eee)
Frame format=0
Stack from 009cbf18:
        00000000 80155c8c 00000000 8017b101 ffffff49 efdfefc9 009b3000 
000938ba
        001302f8 009cbf68 000a1ba2 009b3010 80155c8c 00000ff0 00000000 
00020000
        00020000 009cbf9a 80170f52 801712bc 009cbf7c 000a1ca6 80155c8c 
00000000
        00000000 009cbfac 00097d20 80155c8c 80155c8c 00020000 00000000 
efa9bd4d
        efa90002 00000000 00000004 00000100 00000001 009cbfc4 00097e04 
ffffff9c
        80155c8c 00020000 00000000 efa9bd68 00002988 ffffff9c 80155c8c 
00020000
Call Trace: [<000938ba>] kmem_cache_alloc+0x0/0x6e
 [<001302f8>] strncpy_from_user+0x0/0xec
 [<000a1ba2>] getname_flags+0x40/0x132
 [<00020000>] _I_CALL_TOP+0x85c/0x1900
 [<00020000>] _I_CALL_TOP+0x85c/0x1900
 [<000a1ca6>] getname+0x12/0x18
 [<00097d20>] do_sys_open+0x32/0xce
-----------------------------------------

Earlier getname_flags() was shown to be the place
where things went south, but I think above back
trace is more correct.

(There seems to be something fishy in kernel <->
userspace interface, I've seen Linux to use
use exception handling liberally when accessing
all kinds of things, instead of it e.g. checking
for NULL pointers etc.  And for some reasons that
still doesn't work properly in Hatari.)


	- Eero