Bananmos wrote: ↑Sat Jun 27, 2020 5:38 pmBut there's a few other things that have been annoying me lately in the otherwise-awesome debugger:
I think 1) and 2) are probably the same issue here? As far as I can tell, labels that start with a @ work properly in the watch window. However, Mesen cannot properly deal with multiple labels pointing to the same address, so in your @foo = TEMP and @bar = TEMP example, it will only keep either one of the labels (e.g @foo) and use that one everywhere, making it impossible to use @bar in the watch, and making all occurrences of @bar in the disassembly show up as @foo.
There is no easy way around these issues - fixing them would require Mesen labels to have a concept of label scope (e.g like CA65 has), which would require a lot of effort/changes (I tried implementing this once in the past and quickly realized it required far too much effort) The watch window/expression/etc also have no direct knowledge of CA65's symbols, so they rely on the (more limited) labels that are created based on the CA65 symbols. Potential "solutions" might be:
-Disabling the import of labels completely in the integration settings - this would remove all labels from the disassembly though, which isn't great either.
-Concatenating all label names that point to the same address together - this could very quickly become unusable for frequently re-used memory addresses, and isn't very intuitive.
-Using source view and just ignoring the disassembly view altogether - but this still leaves issues with not being able to use the watch window 100% reliably. Fixing this would require to make the watch aware of the ca65 symbols, which would require the c++ core to know about the ca65 symbols since the watch relies on expressions, which are evaluated in the C++ core (CA65 integration is entirely a UI-side feature at the moment, and I would prefer to keep it this way if possible)
As for 3/4, step back is definitely not perfect - I've tried and fixed issues with it several times, but more always get reported. Basically it loads the most recent save state stored in the rewind cache, and then replays the input for however many frames needed, until it reaches the instruction that ran before the instruction that was about to run. In the past there have been issues when used in the first ~30 frames after a reset/power cycle, or after loading a state, for example, but I think those should mostly be fixed, although I think fiskbit reported something with regards to that again, not too long ago. I'll try to take a look, but unless I can find the conditions to reproduce it, it might be somewhat tricky to fix.
Step back is a feature that originally took me an hour to get to work for the most part, and then forced me to waste an additional 10-20 hours on debugging issues with it :P (and there are more issues, beyond this - e.g stepping back will screw up the call stack window, for example)
So with all that said, it's 3) is basically why I'm not too keen on doing 4), in the sense that adding more features to an already somewhat buggy feature isn't great, heh. Other people have also asked to be able to rewind to the previous breakpoint, for example, etc, and that's also not too trivial for other reasons, etc. The current way the step back works makes it limited to stepping back anywhere between 0 instructions to 30 full frames, but never more, due to its reliance on the rewinder's code, which is another thing that might need to be fixed before adding any more functionality to it.