WinUAE 4.3.0 mishandles trapcc

[saimo]

Toni, sorry for not reporting this directly on GitHub, but I can't be bothered to register over there Also, I've searched around a little bit, and it seems that this issue is not known yet.

I've just stumbled over this: the emulation of trapcc puts the address of the trapcc instruction itself in the supervisor stack, not the next instruction's. Here's an example log:

>fi 56fc
  D0 00002111   D1 FFFF002F   D2 FFFF0000   D3 FFFFFFFF
  D4 00000000   D5 00000000   D6 00000101   D7 08A8FFFF
  A0 08A825DC   A1 08A825DC   A2 0000E556   A3 08A8015C
  A4 00BFD000   A5 08A817A0   A6 00DFF000   A7 08AA89A4
USP  08AA89A4 ISP  08002318 SFC  00000001 DFC  00000000
CACR 00003111 VBR  0A222048 CAAR 00000000 MSP  00000000
T=00 S=0 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=0 STP=0
Prefetch ffffffff 4e732c78 (1) 293e (1) 56fc (1) 5279 (1)
08A825E0 56fc                     TRAPNE  (T)
Next PC: 08a825e2
>t
Exception 7, PC=08A825E0
Cycles: 8 Chip, 16 CPU. (V=192 H=5 -> V=192 H=13)
  D0 00002111   D1 FFFF002F   D2 FFFF0000   D3 FFFFFFFF
  D4 00000000   D5 00000000   D6 00000101   D7 08A8FFFF
  A0 08A825DC   A1 08A825DC   A2 0000E556   A3 08A8015C
  A4 00BFD000   A5 08A817A0   A6 00DFF000   A7 0800230C
USP  08AA89A4 ISP  0800230C SFC  00000001 DFC  00000000
CACR 00003111 VBR  0A222048 CAAR 00000000 MSP  00000000
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=0 STP=0
Prefetch ffffffff 4e732c78 (1) 5279 (1) 08a8 (1) 500a (1)
08A81548 4e7b 0002                MOVEC D0,CACR
Next PC: 08a8154c
>d 800230c
0800230C 0000 08a8                OR.B #$a8,D0
08002310 25e0                     ILLEGAL
08002312 201c                     MOVE.L (A4)+,D0
08002314 08a8 25e0 0025           BCLR.B #$25e0,(A0,$0025) == $08a82601 [fc]
0800231A 00f8 0205 014b           CMP2.B $0205,D0
08002320 ffff                     ILLEGAL
08002322 0000 0000                OR.B #$00,D0
08002326 0200 127f                AND.B #$7f,D0
0800232A 0801 eb3e                BTST.L #$eb3e,D1
0800232E 0000 0000                OR.B #$00,D0

I've tried all the combinations of 68020/68030 and JIT/non-JIT emulation, and the results were the same.

[Toni Wilen]

It is correct behavior (Trapcc works differently than normal Trap for some reason). Some Motorola documentation is wrong.

[saimo]

In this case the documentation is correct.

Here's a test program I've just whipped up (executable attached):

***********************************************************************************************************************
* This checks whether the return PC stored by trapcc in the stack matches or not the correct one.

_LVOCloseLibrary = -414
_LVOForbid       = -132
_LVOOpenLibrary  = -552
_LVOPermit       = -138
_LVOPutStr       = -948
_LVOSupervisor   = -30

              machine 68020

              movea.l 4.w,a6
              jsr     (_LVOForbid,a6)        ;disable task switching
              lea.l   (.GetVbr,pc),a5
              jsr     (_LVOSupervisor,a6)    ;get vbr
              move.l  ($1c,a5),a4            ;get system trapcc handler address
              move.l  #.HandleTrapcc,($1c,a5);set own handler

              lea.l   string_mismatch,a3     ;preload result string address
              trapne                         ;cause exception (ccr.Z cleared by previous move)
.ReturnPC

              move.l  a4,($1c,a5)            ;restore system trapcc handler
              lea.l   string_DOSLibrary,a1
              moveq.l #39,d0
              jsr     (_LVOOpenLibrary,a6)   ;open dos.library
              tst.l   d0
              beq.b   .exit
              movea.l d0,a6
              move.l  a3,d1
              jsr     (_LVOPutStr,a6)        ;print result string
              movea.l a6,a1
              movea.l 4.w,a6
              jsr     (_LVOCloseLibrary,a6)  ;close dos.library
.exit         jsr     (_LVOPermit,a6)        ;enable task switching
              moveq.l #0,d0
              rts                            ;return success


.GetVbr       movec.l vbr,a5                 ;get vbr
              rte


.HandleTrapcc lea.l   (.ReturnPC,pc),a0      ;get correct return PC
              cmpa.l  (2,sp),a0              ;compare it against PC in the stack
              bne.b   .return                ;if different...
              lea.l   string_match,a3        ;change result string address
.return       move.w   #4,(sp)               ;set sr.Z (so that trapne does not trigger an exception again on WinUAE)
              rte


string_DOSLibrary dc.b "dos.library",0
string_mismatch   dc.b "mis"
string_match      dc.b "match",10,0

If executed on a real 68020 or 68030, it prints "match" (i.e. the PC in the stack matches the address of the instruction after trapne); if executed on WinUAE, it prints "mismatch" (i.e. the addresses don't match). Also, if move.w #4,(sp) were removed, the program would hang forever on WinUAE, because trapne would be executed again upon return and trigger the exception again.

Note: I can test this only on 68020 and 68030; the 68040 and 68060 documentation says that those CPUs behave the same way, and it is reasonable to expect that they indeed do - not just because it makes sense, but also because rte will use the PC as it is (i.e. it won't adjust the PC depending on the stack frame type).

[Toni Wilen]

Hmm.. My recent CPU tester tests should detected that, I'll need to recheck.

btw, some exceptions do stack current PC, some next PC.

[Toni Wilen]

Argh.. 68020+ exception stacked PC was not checked in tester.. Because tester didn't complain and I have found lots of strange CPU side-effects, I assumed incorrect documentation.

[saimo]

Congratulations on having discovered the issue quickly. If that helps fixing other stuff too, we all can be even happier

[Toni Wilen]

Tester fixed and now it reports the error correctly:

CPUlvl=2, Mask=00ffffff Code=0087ffa0 SP=00860400 ISP=00860840
 Low: 00000000-00008000 High: 00ff8000-01000000
Test: 00860000-00900000 Safe: ffffffff-ffffffff
TRAPcc (basic):
trapcc/0000.dat (basic). 0...

0087ffa0 50fa 00f6     trapt    #$f6
0087ffa4 2048     movea.l  a0,a0
0087ffa6 4afc     illegal
Exception 7 stack frame mismatch:
Expected: 00.00.00.87.ff.a0.20.1c.00.87.ff.a0
Got     : 00.00.00.87.ff.a4.20.1c.00.87.ff.a0
Registers before:
D0: 00000010 D1: 00000000 D2: ffffffff D3: ffffff00
D4: ffff0000 D5: 80008080 D6: 00010101 D7: aaaaaaaa
A0: 00000000 A1: 00000078 A2: 00007ff0 A3: 00007fff
A4: fffffffe A5: ffffff00 A6: 0087fea0 A7: 00860400
SR: 0000      PC: 0087ffa0 ISP: 008607c0 MSP: 00860840
T1=0 T0=0 S=0 M=0 X=0 N=0 Z=0 V=0 C=0
Registers after:
SR: 0000/2000 PC: 0087ffa4 ISP: 008607c0 MSP: 00860840
T1=0 T0=0 S=0 M=0 X=0 N=0 Z=0 V=0 C=0
1 (0/32) S=0 E07=1

Note that error is "inverted" because test data is generated from UAE CPU core. But in this case the test is run against real CPU.

[Toni Wilen]

http://www.winuae.net/files/b/winuae.7z should fix it. It is almost time for final 4.4, probably someday in next week.. Very late minute fix, fortunately it was really trivial.

[saimo]

Well done!
Great to hear a new release is near.

[Toni Wilen]

I run basic tests again using fixed tester (real 020, 030 and 060) and found 3 similar exception PC field bugs:

- CHK2
- 68060 only STOP (and LPSTOP) if new S-bit was not set caused privilege violation exception. LPSTOP illegal instruction if second opcode word was not 0x01c0.

[saimo]

No surprise that the problem affected rarely/never used instructions (I mean, otherwise it would have surfaced on its own a long time ago).