Debugger doesn't work

[Dr. MefistO]

Steps ("t", "t 1") doesn't work in 3220.

P.S. Make an infinite loop, allow to debugger stick there, then return original bytes, and try to step. It will do nothing.
In previous version it works.

[Toni Wilen]

Works for me. There is also no debugger changes.

-> Config is always required. Test case is required. It never is that simple.

[Dr. MefistO]

Ok, this is my config and test file.

[Toni Wilen]

It works for me. (exe in df0. Perhaps you have some cache setup stuff in your HD installation? Cache, especially 68040+ instruction cache can cause side-effects.

[Dr. MefistO]

Video about the bug: [ Show youtube player ]

[Dr. MefistO]

Originally Posted by Toni Wilen

Perhaps you have some cache setup stuff in your HD installation? Cache, especially 68040+ instruction cache can cause side-effects.

What does it mean? How to clear a cache?

[Toni Wilen]

It is not about clearing or not but trying to duplicate your config. Always try without HD because it can change lots of things.

Boot without startup-sequence or remove your harddrive and insert the exe in df0:, does it work now? Then boot without startup-sequence, run setpatch, does it still work?

[Dr. MefistO]

Originally Posted by Toni Wilen

Boot without startup-sequence

I don't have any startup-sequences.

Originally Posted by Toni Wilen

or remove your harddrive and insert the exe in df0:, does it work now?

Nope. =(

Originally Posted by Toni Wilen

Then boot without startup-sequence, run setpatch, does it still work?

Where is it "setpatch"?

P.S. I have tried to change CPU type, but without success.

[Dr. MefistO]

...but "z" step is working. Video: [ Show youtube player ]

[Toni Wilen]

Wait a minute, you modify the code in debugger and you never mentioned it?
That surely won't work because CPU cache does not see the modification, just like real CPU will not see it. (68040+ probably didn't emulate cache at all in older version without cycle exact mode, thats probably why it appeared to work previously)

Switch off "more compatible" to disable CPU cache emulation. Or disable/flush caches, just like you would do it with real hardware. But don't ask in this thread, it has nothing to do with emulation and it is not my problem

[Dr. MefistO]

CPU mode is not important to me. So, I just want to use this situation normally.
What I should to do then?

[Toni Wilen]

Originally Posted by Dr. MefistO

CPU mode is not important to me. So, I just want to use this situation normally.
What I should to do then?

Do you mean 68020 without more compatible CPU option ticked does the same?

And what are you exactly trying to do? Unless you didn't mention something else, running your test program, breaking to debugger, then using "t" works as expected for me. Exact steps are needed. (Not a video!)

[Dr. MefistO]

I want to break at the first instruction of not my program (console program).
I have replaced first 2 bytes with infinite loop. Then, after restoration of these bytes, I want to do one step (step into). But, as you see in this video, it doesn't work for me.
CPU is not important for me, I just want to break and step (at any CPU).

P.S. Without "More compatible" it works. =) Hmm...

[jotd]

you could put a breakpoint instead with "f".

BTW Toni I tried "fi NOP" and it did not work great tool besides that!! lacks some ergonomy/resizable windows but you can't have everything.

[Dr. MefistO]

Originally Posted by jotd

you could put a breakpoint instead with "f".

Where I should set breakpoint, if I don't know at what address my program will be loaded?

[Toni Wilen]

Originally Posted by jotd

you could put a breakpoint instead with "f".

BTW Toni I tried "fi NOP" and it did not work great tool besides that!! lacks some ergonomy/resizable windows but you can't have everything.

fi 4e71

Originally Posted by Dr. MefistO

Where I should set breakpoint, if I don't know at what address my program will be loaded?

Don't use break points, they only make sense if code runs in absolute addresses. Write or read some absolute "debug" address in your code and set memwatch breakpoint.

For example "w 0 100 4 w" will break when writing to address range $100-$103.

(note that I don't use "gui" debugger, it is totally unsupported. xx to switch modes)

[jotd]

Thanks Toni.
With lowlevel stuff, the WinUAE debugger is the only one that works.
All other monitors stumble on classic amiga problems (display,timers) + JIT.