Debugger doesn't start
Toni, when I launch every ADF from a quickconfig (it doesn't matter which) after the first SHIFT-F12 (that works) subsequent attempts to start the debugger (CLI or GUI) does not do anything (other keys work normally).
My hdd workbench environment doesn't seem affected. Thanks! Found the first not working version: 4010b6 |
Latest PB0 (21/07/2018) seem to work.
I'll do other tests. Thanks. |
I am still not sure how it happens (I saw it once or twice but never could duplicate it..) but it was related to STOP debugging update.
|
Quote:
I'm writing a little snippet and when I use "z" or F11 to execute a _WaitTOF() the program ignore the stop at next instruction, thrown an Arabuusimiehet.WinUAE window with "Exception 27, pc=somewheretomycode" and continue. Never seen before. |
Hi Toni, I keep having problems with the internal debugger.
The hung at SHIFT-F12 is no longer here, but there are other little things that do not works like they should. It seems that in some cases the watchpoints (w x command, with x>0) are not respected, or certain breakpoints are not triggered. I cannot give you precise details because everything happens in a seldom/random way. It seems to happen often after completely changing configuration without closing and restarting WinUAE (yes, 'Restart' menu button change nothing). Sometimes you have to shut down WinUAE because you can not get out of a HALTx situation in any way. Can be somehow still related to STOP update? I find myself using 3.x versions to avoid all this... I know I did not helped you much, I'm sorry :sad However a problem always manifests itself: simple f command (stop at bootblock code init) no longer works. |
Plain "f" now works (nothing to do with STOP or anything), also better than previously because it now does not anymore break if LVO (JMP xxxxxx) is executed in RAM.
|
Quote:
Thanks! |
I'm not opening a new thread for this...
How can I interpret the "mustchange" for the w command? w <num> <address> <length> <R/W/I/F/C> [<value>[.x]] (read/write/opcode/freeze/mustchange). I expected that with a command like this I would take a breakpoint if a part of the affected memory was modified with CPU or blitter: w 0 56e98 200 C ALL But nothing happen. Is not the right syntax? What mean opcode and freeze? Thanks. |
Freeze = any write gets ignored. Original memory value never changes.
Mustchange = only breaks if written to and value is different than old value in memory. Opcode = only instruction opcode fetches are checked. Data read and writes ignored. |
Quote:
But what's the problem with my command line? I made a "mustchange" event (changing a memory value, with CPU or Blitter), nothing happens. |
You still need to add W parameter. Without it all accesses are ignored (default is "nothing"). It isn't very logical and it isn't really supposed to be either :)
|
Quote:
Thanks! |
Quote:
This time i've got something replicable. When Amiga system got trashed i've a situation like this: Code:
Memwatch 0: break at 0000000A.W I 00000000 PC=00000004 CPUI (000) Code I'm debugging is perfectly working without the added watch. Logically if I continue this code system crash or halt (i've some very rare case where even WinUAE crash). So last debug i've done I have been very attentive to the use of watchpoints. And got this replicable crash: - WinUAE 4.1.0 beta 8 from sticky thread or final 4.0.1 from WinUAE site (64bit version) used; - Quickstart A500 KS 1.3 512+513 (most common) started with inserted floppy (I was debugging DanDareIII-TheEscape.ipf) [but both selections are not so significative]; - start emulation and wait CLI window appear and game begin the load; - during the very first load time start debug and: Code:
00FC0F94 60e6 BT .B #$e6 == $00fc0f7c (T) Code:
Memwatch 0: break at 00000002.W I 00000000 PC=00000000 CPUI (000) Surely the previous one occurred during a long debugging session and I do not remember which memory cells I modified, but the casuistry is identical. Fortunately this last combination is very simple and always repeatable so it can help Toni to understand where the problem is. Cheers. PS: if anyone is wondering why I used W 0 80 is to catch a stupid bug in game module replayer that give some 'strange' volume effect at start in some configuration |
Quote:
|
Quote:
And you are right also for bug type, is an initialisation bug. An uninitialized pointer that read a table and set a variable volume as: (positive_value*multiplicative_factor)++, else abs(negative_value) and stop. So if you set $0=#$80 (W 0 80) you can stop strange volume behaviour (yes, ugly, but is non-system game so..). Anyway I'll sure give a look in your code (it's EP replayer, right?). Thanks! :) However, it is only a coincidence the crash of WinUAE with this game, it is simply the last one I was patching. It happened on other occasions. Sooner or later I must also remember to ask Toni to insert some breakpoint methods that I saw in the Hatari debugger. They seemed excellent (used for Monkey B.'s recover). :great |
Quote:
|
Quote:
|
It is KS 1.3 weirdness. Nothing to do with WinUAE.
Set break point at C0898E and check what it does. (No, I have no idea what it tries to do..) |
Quote:
(i've noticed some strange code in KS1.3 that do a 'copper' search from $0 but sure do not trash all like this and is totally unrelated). At c0898e i've nothing significative. And I've something really similar also on Quickstart A600 (KS2.05) config: Code:
Memwatch 0: break at 00000002.W I 00000000 PC=80000000 CPUI (000) Surely it's my mistake but I do not understand exactly where it could be.. EDIT: strange output to the H command after the w trap: Code:
>H |
I only get expected memwatch hit when that weird code reads from address zero. I can't duplicate anything else.
Note that I used simply WB 1.3 disk because you said it isn't important which disk is in use, just to boot it in CLI. |
All times are GMT +2. The time now is 22:40. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.