Re: [hatari-devel] Problems with some FPU tests

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


On Montag, 23. April 2018 19:12:51 CEST Thomas Huth wrote:

> You mean "--log-level debug" instead of "--trace debug"

 

Ehm yes.

 

>Well, that explains the ugly crash: The "--tos none" mode does not set

>up any exception handlers,

 

Yes, i already noticed that. I think there should be some minimal setup for at least bus error and illegal exception handler, that just terminates the program with some code != 0, otherwise you won't be able to test wether illegal opcodes really behave as expected.

 

>Also below you already use --cpulevel 3 ... not --cpulevel 0 as you mention it later?

>Now --cpulevel 0 ? ... copy-n-paste bug?

 

No i think it was correct. The first test was run from the script, without loading a default config, and with --cpulevel 3 (but without explicitly setting fpu, so it was still off). The 2nd test was run from the command line, with a default hatari.cfg setup for TT (cpulevel and with fpu), and specifying --cpulevel 0 on the command line, thus the message in the log that FPU was turned off. The 2nd run terminated with a segfault.

 

>Hatari should certainly not segfault in this case. Could you attach a

>gdb and get a backtrace?

 

Without debug information, i only get:

 

#0  0x00000000005fe9a8 in Screen_GenConvert ()
#1  0x000000000060357f in Screen_GenDraw ()
#2  0x0000000000611450 in Video_RenderTTScreen ()
#3  0x00000000006142e5 in Video_InterruptHandler_VBL ()
#4  0x0000000000656ce7 in m68k_run_2 ()
#5  0x0000000000652fea in m68k_go ()
#6  0x00000000005a1445 in main ()

With configuration Debug (which still seems to add some optimization flags) i get

 

#0  0x00000000005dd73e in ScreenConv_BitplaneTo32bppZoomed (coefy=2, coefx=<optimized out>, lowerBorder=0, upperBorder=0, rightBorder=0, leftBorder=0, hscrolloffset=0, nextline=160, vbpp=4, vh=40191600,  
   vw=21127456, scrheight=80383200, scrwidth=1280, hvram=<optimized out>, fvram=0x1406be0 <STRam>) at /home/sebilla/atari/hatari/src/screenConvert.c:798
#1  Screen_ConvertWithZoom (lowerBorder=0, upperBorder=0, rightBorder=0, leftBorder=0, hscrolloffset=0, nextline=160, vbpp=4, vh=40191600, vw=21127456, fvram=0x1406be0 <STRam>)
   at /home/sebilla/atari/hatari/src/screenConvert.c:1047
#2  Screen_GenConvert (fvram=0x1406be0 <STRam>, vw=vw@entry=640, vh=vh@entry=480, vbpp=vbpp@entry=4, nextline=nextline@entry=160, hscroll=0, leftBorderSize=0, rightBorderSize=0, upperBorderSize=0,  
   lowerBorderSize=0) at /home/sebilla/atari/hatari/src/screenConvert.c:1077
#3  0x00000000005de864 in Screen_GenDraw (vaddr=0, vw=640, vh=480, vbpp=4, nextline=160, leftBorder=leftBorder@entry=0, rightBorder=0, upperBorder=0, lowerBorder=0)
   at /home/sebilla/atari/hatari/src/screenConvert.c:1101
#4  0x00000000005e9025 in Video_RenderTTScreen () at /home/sebilla/atari/hatari/src/video.c:4119
#5  0x00000000005eb23a in Video_DrawScreen () at /home/sebilla/atari/hatari/src/video.c:4155
#6  Video_InterruptHandler_VBL () at /home/sebilla/atari/hatari/src/video.c:4335
#7  0x000000000061b3ad in m68k_run_2 () at /home/sebilla/atari/hatari/src/cpu/newcpu.c:7223
#8  0x00000000006185ae in m68k_go (may_quit=may_quit@entry=1) at /home/sebilla/atari/hatari/src/cpu/newcpu.c:7531
#9  0x00000000005ced6c in M68000_Start () at /home/sebilla/atari/hatari/src/m68000.c:284
#10 0x00000000005cfe0a in main (argc=20, argv=0x7fffffffd578) at /home/sebilla/atari/hatari/src/main.c:942

>Or could you provide your test-inf.ttp so I could have a try?

 

Attached below, ttp, source and script i was using. It has slightly changed in the meantime, but still gives the same behaviour.

 

>Then look for the place where the CPU

>jumps to an address below 0x1000

 

See backtrace above. Seems to be related to video conversion, not cpu emulation. If you still need the disasm trace, let me know.

 

PS.: the ttp contained in the zip was compiled with the m68k-atari-mint-gcc cross compiler, and using a modified version of Markus's libcmini (and another small patch to Hatari to redirect Fwrite(2) to stderr when run without TOS). That should make writing tests much easier. Would there be Interest to include that in Hatari?

 

Attachment: test-inf.zip
Description: Zip archive



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/