SMC detection

[StingRay]

I have just tried to use the WinUAE debugger to find some SMC and it doesn't appear to work for me. I made some simple test code and the debugger didn't break with "smc 1". I have used the following code for testing (using a standard 68000/A500 config):

START    lea    SMC(pc),a0

.LMB    btst    #6,$bfe001
    bne.b    .LMB


    move.w    #$4e71,(a0)
    ;rts
    tst.w    d0
    clr.w    d1


SMC    rts
    rts

I have added the bogus tst/clr dx instructions after the first test to make sure the short distance to the modified instruction isn't the problem but it didn't change anything.


What am I missing here?

[jotd]

I remember having such problems. But have you turned off JIT? because with JIT it's guaranteed that it DOESN'T work.

My whdload setup as some magical winuae start/stop command to turn on/off JIT & turn off/on MMU when running whload.

that would be super-cool if it worked, because whdload protectSMC is fairly limited, and there are a lot of SMC games out there...

[StingRay]

JIT is of course turned off (68000/A500 config as mentioned). When doing WHDLoad stuff I always have JIT turned off as well. It would indeed be nice if the SMC detection worked, could save quite a bit of time.

[musashi5150]

I think oldskool debuggers used to put ILLEGAL (or something) to trap breakpointed code through a vector. I wonder if UAE is doing something similar (with some clever slight-of-hand-magic so the Amiga can't see the value) rather than watching the PC - and you lose the magic when you SMC.

But I'm just guessing and quite possibly talking sausages

[Toni Wilen]

Memwatch point handling changed many releases ago and it affected smc (and few other debugger options).

You need to add "dummy" memwatch range, for example "w 0 0 80000 none" if code is in chip ram. (I guess some shortcut to add all ram regions would be nice to have..)

"More compatible" CPU option also must be ticked.

[StingRay]

That does indeed work, thanks! And yes, a shortcut to add all the ram regions would be incredibly useful indeed.

[jotd]

Some day I'll have to read the WinUAE reference manual, well, better read Toni's mind

[Paradroid]

I've tried looking and failed to find any info/notes about memwatch changes, so what happened with it?

I ask as my usual method of triggering a breakpoint in my code is to add "clr.w $80000" at the point I want to break, then use "w1 80000" in the debugger. This has worked fine until I tried it today, so I started installing older versions of winua and found that it stopped working as of version 3.6.0

The "More Compatible" option is ticked in my config, although it's greyed out.


Do I need to type something different in the debugger now?

[Toni Wilen]

w has always needed size parameter (w <num> <address> <length> [optional stuff]>. It probably was accidental side effect if it worked without it previously.

[Paradroid]

Originally Posted by Toni Wilen

w has always needed size parameter (w <num> <address> <length> [optional stuff]>. It probably was accidental side effect if it worked without it previously.

It would use a size of 1 if not specified, but I've just tried again using "w1 80000 2" to be sure and it's still not working in 3.6.0 ~ 4.0.1

However, I should have mentioned that I'm using the GUI debugger, and I've just been reading the "UAE debugger updates" thread and noticed your "Don't mention anything about GUI." comment. Does this mean the GUI debugger is now effectively dead?

EDIT: I just tried "w0 80000" and it works.

[jotd]

I noticed that if you don't have watchpoint 0 active then the others don't work.

Also the trainer feature (C command) doesn't work anymore (deep trainer works). And yes, the GUI version is not maintained anymore. I got used to the text mode, with proper colors & quick edit mode it's good enough

[Toni Wilen]

Memwatch checking was optimized and it accidentally required that first slot is in use. Fixed.

[jotd]

It works but a little too well. In fact, it seems to "prefetch" the next instruction.

>g
SMC at 00011118 - 0001111A (2) from 00011094
Cycles: 9767 Chip, 156272 CPU. (V=152 H=213 -> V=195 H=219)
  D0 00000000   D1 0000F800   D2 0007F800   D3 0000FFFF
  D4 00000000   D5 FFFF0000   D6 00000FF8   D7 00000009
  A0 000536C0   A1 00063296   A2 00030AB2   A3 00072536
  A4 00031A6A   A5 0003142A   A6 00000000   A7 000005A4
USP  0007FC00 ISP  000005A4 SFC  00000005 DFC  00000005
CACR 80008000 TC   00008000 ITT0 00000000 ITT1 00000000
DTT0 00000000 DTT1 00000000 VBR  483F6000 MSP  0007F800
MMUS 00000000 URP  483EA000 SRP  483EA000
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=3 STP=0
00011100 23c8 00df f04c           MOVE.L A0,$00dff04c
00011106 23c8 00df f054           MOVE.L A0,$00dff054
Next PC: 0001110c
>d $11094
00011094 23c5 0001 1116           MOVE.L D5,$00011116 [ffff0000]
0001109A 5489                     ADDA.L #$02,A1

>d $11114
00011114 4e75                     RTS
00011116 ffff                     ILLEGAL
00011118 0000 48a7                OR.B #$a7,D0
0001111C f000 0640                [ MMUOP030 D0,#$0640 ]

The error clearly points in a data zone (just after & before some code). Badly written as data should be in another area, but that's life. But SMC detector trips a lot on single long/word data surrounded by actual code.

Also, be aware that you need to reduce WinUAE memory (I've set 2mb chip & 4mb fast) or the PC freezes when entering "SMC 1". Strange, as the memory watched is always 0->80000.

[Toni Wilen]

It detects any instruction fetch access which includes prefetches, it does not (and can't) know if CPU "uses" the fetched opcode word.

68000 + more compatible mode has extra checks to detect some branch-like instructions (mainly RTS/RTD/RTE/RTR and BRA.B). It possible to add same support for 68020+ more compatible. If more compatible is off, it should also disable prefetch emulation.

Memory size shouldn't make any difference as long as all memory is inside first 16M (24-bit addressing).

[jotd]

But if I disable "more compatible", I don't have any hits at all when there's blatant SMC. It disables false alarms but also true alarms...

Besides, even if caches are flushed between modification and execution, smc is detected.

So this is still useful (specially without breakpoint so you can post-process the output with a python script afterwards and group hits, filter, check source code at the same time to remove false alarms... and all) with those issues...

[Toni Wilen]

Originally Posted by jotd

But if I disable "more compatible", I don't have any hits at all when there's blatant SMC. It disables false alarms but also true alarms...

It works as designed. Only "more compatible" (prefetch) mode does indirect opcode memory reads, all other modes does direct access (for better performance), bypassing any memory bank redirections.

It would require changes to CPU cores to detect between opcode was prefetched vs opcode was prefetched and it was actually used later. This won't happen. Sorry.

Besides, even if caches are flushed between modification and execution, smc is detected.

4.9.2+ betas clear smc detections when 68020+ caches are flushed.

[jotd]

Ok I understand! either you get prefecth+memory banks or you get direct memory access and no memory watches.

it's already very good if cache flush cancels the false alarms. I can deal with the other false alarms with a config file / post processing. Thanks

[paraj]

Think I've spotted a minor issue with the detection code. If the modification isn't aligned with the prefect fetch size (2 for 68000, 4 for 020+) it's not caught. E.g.

00024fa8 33fc 4e71 0002 50b2      move.w #$4e71,$000250b2
...

Is not picked up since the prefetch reads a longword from $000250b0. Same goes for modifying just the second byte of an instruction on 68000.

Check probably needs to be something like:

-    hitpc = smc_table[addr].addr;
+    hitpc = 0xffffffff;
+    for (i = 0; i < size && hitpc == 0xffffffff && addr + i < smc_size; i++)
+        hitpc = smc_table[addr + i].addr;
     if (hitpc == 0xffffffff)
         return;

[Toni Wilen]

It was not (at least originally) meant for 68020+. 68000 is 16-bit only.

[CFou!]

Originally Posted by Toni Wilen

Memwatch point handling changed many releases ago and it affected smc (and few other debugger options).

You need to add "dummy" memwatch range, for example "w 0 0 80000 none" if code is in chip ram. (I guess some shortcut to add all ram regions would be nice to have..)

"More compatible" CPU option also must be ticked.

I thought SMC was broken and had long since given up using it.

thank you for the information