Feature request: Support for watches

[sdsnatcher]

Note: Not to be confounded with watchpoints (special type of breakpoint).

Most debuggers have a watch feature (usually a dockable or window), where you can add variables to be watched.

It would be nice to have such a feature on openMSX-debugger too, to be able to watch specific variables (bytes or words, by label), memory addresses, I/O ports, or any address of any of the debuggables that openMSX provides (like a PSG register), without having to scroll to these whole debuggables all the time.

And like the watch window of other debuggers, it should allow you to set a value for the watch there too.

[m9710797]

I'm not sure I fully understand the request. Though it sounds similar to the existing ram_watch utility (type help ram_watch in the openMSX console). It this what you wanted? If not, then please provide more details.

[MBilderbeek]

I guess @sdsnatcher means something like ram_watch with addresses given by symbols, but apparently not only RAM but 'any debuggable address watch'. So that's a lot more than what is in that utility now.

[sdsnatcher]

It this what you wanted? If not, then please provide more details.

It all comes to the use case and productivity. An answer to this question requires a broader view than the scope of this feature request, but here it goes. I hope it helps with many other design decisions of the openMSX & debugger team:

1) Anything debug-related done on the console is ephemeral. Once you close the openMSX App, it's gone. You have to type everything again next time. Not productive at all. OTOH, when you add breakpoints/watchpoints/conditions etc on the debugger, they're persistent between openMSX sessions. No need to type all of them again every time. It's a whole universe better in terms of productivity. And, believe me, we MSX developers need to use quite a lot of points to debug an MSX game. And this is not a modern operating system: The entire MSX has to be restarted every time you make a modification/recompile the game. Trying to make a running openMSX App re-run your recompiled executable by using rewind will result in a lot of alarming messages being printed on the console about data corruption. No-go. 2) The same applies for multiple simultaneous openMSX Apps. The debugger is always kept open and smoothly transplants all these debugger points between multiple simultaneous openMSX apps without hassle. How not to fall in love with this? 🙂 3) The debugger has a load/save session feature. This allows me to have a RealLife(TM) besides the hobby. Something important has shown up? Save the session with all your points and (some) window placements, stop the hobby and go deal with the RealLife(TM). Reload the session and continue later without having to type tons of commands again. a) Supplementary bonus: I can have different debugger sessions saved for different parts of the game that run on the same memory area, since we're talking about an MSX computer with a small memory where an MSX-DOS game loads different DOS executables for every part of the game (intro, game engine, cutscenes, menus, music mode, etc). Each executable has its own specific set of *points, labels, Symbol Manager files, etc b) Trivia: Most of the Japanese MSX disk-based games are in fact MSX-DOS apps in disguise, with a customization of the DOS to work with a proprietary file system. This was done as a copy protection measure, I suspect. 4) The console doesn't know how to deal with labels. It only accepts hardcoded addresses. This makes most of its debug-related commands almost useless when you're developing an MSX app, since the majority of the addresses change on every compilation. It's fluid by nature, while the console commands are all static. 5) ram_watch, as @MBilderbeek already explained, is limited to RAM. It can't watch any of the other plethora of debuggables that openMSX has. The only way to watch values on other debuggables is to open more generic hex-viewer debuggables on the debugger and try to remember yourself which addresses of which debuggable you had to watch. Not exactly productive. To add insult to injury, all these generic hex-views rewind to address 0x0000 every time you had to close the debugger and open it again, and you have no way to directly type an address in them, so there I go scrolling through the whole 128KB of VRAM by hand back to where I was watching, rinse and repeat. 😅

PS: The word "session" was used to describe two different type of sessions here: openMSX-emulator sessions (anything that happens between its boot until it's closed) and openMSX-debugger sessions (debugging a specific executable of an MSX game). Those two have very different life spans. I hope I was able to express which is which in the text above.

[m9710797]

Hi,

Not really an answer to this request, but anyway ... (this is about the external debugger, not the new integrated ImGui debugger) ...

The new ImGui debugger has a feature called "Watch expressions". Here's the help text that comes with this feature:

The given (Tcl) expressions are continuously evaluated and displayed in a nicely formatted way.
Press the 'Examples' button to see some examples.

There are 4 columns:
* description: optional description for the expression
* expression: the actual Tcl expression, see below
* format: optional format specifier, see below
* result: this shows the result of evaluating 'expression'

Add a new entry via the 'Add' button, then fill in the appropriate fields.
To remove an entry, first select a row (e.g. click on the corresponding 'result' cell), then press the 'Remove' button.

You can sort the table by clicking the column headers.
You can reorder the columns by dragging the column headers.
You can hide columns via the right-click context menu on a column header. For example, once configured, you may want to hide the 'expression' and 'format' columns.

The expression can be any Tcl expression, some examples:
* [peek 0x1234]: monitor a byte at a specific address
* [reg SP] < 0xe000: check that stack hasn't grown too large
                     (below address 0xe000)
If you have debug-symbols loaded (via the 'Symbol manager'), you can use them like:
* [peek16 $sym(mySymbol)]: monitor 16-bit value at 'mySymbol'
There's a shorthand notation to peek 8-bit values:
* <integer> -> [peek <integer>]
* <symbol>  -> [peek $sym(<symbol>)]

In the format column you can optionally enter a format-specifier (for the  Tcl 'format' command). Some examples:
* 0x%04x: 4-digit hex with leading zeros and '0x' prefix
* %08b: 8-bit binary value
* %d items: decimal value followed by the string " items"

The examples are (in the GUI they are shown in a nicely formatted table):

description: "peek at fixed address"
expression: "[peek 0xfcaf]"
format: "screen=%d"

description: "VDP command executing"
expression: "[debug read \"VDP status regs\" 2] & 1"
format: ""

description: "PSG enable-channel status"
expression: "[debug read \"PSG regs\" 7]"
format: "%08b"

The following 2 require an appropriate symbol file

description: "value of 'myLabel'"
expression: "$sym(myLabel)"
format: "0x%04x"

description: "peek at symbolic address"
expression: "[peek16 $sym(numItems)]"
format: "%d items"

If I understand correctly this covers your request:

• Really anything that can be viewed/queried can also be "watched".
• The expressions are re-evaluated on every host-frame, so the shown result is always up-to-date. (e.g. also when running the MSX at 1% speed, or when single-stepping, ...). This would be impossible to implement in the external debugger.
• You can use symbols in the expression. When you reload a symbol file the expression uses the (possibly) new symbol-value.
• The list of watches (and also the list of symbol files) is saved/restored when you restart openMSX.

Please give the "imgui" openMSX branch (with integrated debugger) a try. It's still work in progress, but it's starting to work nicely. Most, but maybe not 100%, of the functionality of the old (external) debugger is now available in the new (integrated) debugger. And some functionality is only present, or works better, in the new debugger. But as I said: it's still work in progress. So (early) feedback would be highly appreciated.

Thanks.

Wouter

PS: it's unlikely this feature will ever be implemented in the old (external) debugger. Should we keep this ticket open?

[MBilderbeek]

@sdsnatcher did you try the latest development build to determine whether that implements your request?

[sdsnatcher]

Hi Manuel!That message arrived when I was on a very busy period in my life, so I ended up forgetting about it later.I can’t test it now since I’m AFH on vacation, but I’ll try to check it after I come back.On 18 Feb 2024, at 07:31, Manuel Bilderbeek @.***> wrote: @sdsnatcher did you try the latest development build to determine whether that implements your request?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>