Re: [hatari-devel] Possible bug in 060 exception stack frames

[Toni Wilen <twilen@xxxxxxxxxx>]

>> I still don't see them being executed.
>
> With trace in Hatari? Or what do you mean? They don't produce output
> except a final "passed" if everything is ok.
ftest.sa does not include them.

Disassembly of test code before first FMOVEM test:

08123B86 f23c 4c18 c123 0001 2345 6789 1234 5678 FABS.P
#$c12300012345678912345678,FP0
08123B96 42ee fea4                MOVE.B CCR,(A6,-$015c) == $0848c988
08123B9A 48ee 7fff ffc0           MOVEM.L D0-D7/A0-A6,(A6,-$0040) ==
$0848caa4
08123BA0 f22e f0ff fec0           FMOVEM.X FP0-FP7,(A6,-$0140) == $0848c9a4
08123BA6 f22e bc00 fea8           FMOVEM.L FPIAR/FPSR/FPCR,(A6,-$0158)
== $0848c98c
08123BAC 2d7c 3e66 0000 ff20      MOVE.L #$3e660000,(A6,-$00e0) == $0848ca04
08123BB4 2d7c d0ed 23e8 ff24      MOVE.L #$d0ed23e8,(A6,-$00dc) == $0848ca0
08123BBC 2d7c d140 35bc ff28      MOVE.L #$d14035bc,(A6,-$00d8) == $0848ca0c
08123BC4 2d7c 0000 0108 feb8      MOVE.L #$00000108,(A6,-$0148) == $0848c99c
08123BCC 41fa ffb8                LEA.L (PC,$ffb8) == $08123b86,A0
08123BD0 2d48 febc                MOVE.L A0,(A6,-$0144) == $0848c9a0
08123BD4 61ff 0000 0ce4           BSR.L #$00000ce4 == $081248ba
08123BDA 61ff 0000 0d10           BSR.L #$00000d10 == $081248ec
08123BE0 4280                     CLR.L D0
08123BE2 4e75                     RTS

Note: Ends to RTS -> FMOVEM tests skipped.

Source of same test:

effadd_1_pc:
	fabs.p		#0xc12300012345678912345678,%fp0

	move.w		%ccr,SCCR(%a6)
	movem.l		%d0-%d7/%a0-%a6,SREGS(%a6)
	fmovem.x	%fp0-%fp7,SFPREGS(%a6)
	fmovem.l	%fpcr/%fpsr/%fpiar,SFPCREGS(%a6)

	move.l		#0x3e660000,IFPREGS+0x0(%a6)
	move.l		#0xd0ed23e8,IFPREGS+0x4(%a6)
	move.l		#0xd14035bc,IFPREGS+0x8(%a6)
	move.l		#0x00000108,IFPCREGS+0x4(%a6)
	lea			effadd_1_pc(%pc),%a0
	move.l		%a0,IFPCREGS+0x8(%a6)

	bsr.l		chkregs
	tst.b		%d0
	bne.l		error

	bsr.l		chkfpregs
	tst.b		%d0
	bne.l		error

Note: FMOVEM test follows, no RTS.

fmovml_0:

ftest.sa contents:

	.dc.l	0x61ff0000,0x0d104280,0x4e7552ae,0xfea04cfb /* 00000790 */

Note 0x4e75 in ftest.sa -> FMOVEM tests are skipped.

> I think we are talking about different things here. Its probably fine
> if inexact/overflow etc. do not work reliably with native emulation
> (i think in aranym its the same). But its the instruction itself
> that causes an address error (maybe because of a corrupted stack
> frame) when executing fmovem.l with a dynamic register list, and not
> using softfloat. That should not happen. Atleast that will crash the
> tests, i don't think that any compiler will produce such an
> instruction.
I meant that it can still crash if FMOVEM handler executes some strange
FPU instructions and then uses for example FPCR contents as an index to
some subroutines. (I didn't check if it does that, need fixed ftest.sa
first)

Or did you mean it crashes even if it does not generate any
unimplemented exceptions?