Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Bananmos
Posts: 532
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Post by Bananmos » Sun May 10, 2020 9:05 am

Sour wrote:
Sat May 09, 2020 10:25 am
Ah, I probably broke the modulo operator back when I added support binary values (e.g "x == %00010001"). Might have to change the operator for one of them, but I'll try and see if it's simple to keep them both in with the '%' operator.
Ah, I see. No worries about using a different operator if it makes things simpler. I'm happy to use something like "Y MOD 4", and keeping the widepsread % prefix for 6502 binary numbers is probably more important than the aesthetics of module.
Sour wrote:
Sat May 09, 2020 10:25 am
I think the assert(Y & 3 == 0) part is an order of operation problem? It's doing 3 == 0 -> false/0, and then Y & 0, which is always 0, so the assert always triggers. "(Y & 3) == 0" should work, though.
Ah, the old ordering gotcha! Shall use parantheses more carefully in the future :)

User avatar
za909
Posts: 216
Joined: Fri Jan 24, 2014 9:05 am
Location: Hungary

Re: Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Post by za909 » Sat May 16, 2020 10:39 am

Hi, I'd like to make a suggestion. During my DPCM-PCM endeavors I really could've used some of the still hidden stats of the APU, namely the 8-bit DPCM buffer state, which if I am not mistaken is implemented as a bit shifter, so there is no separate bits remaining counter. Seeing the state of this would've made determining timings a bit easier, since I had no idea when the buffer was going to run out of bits and start an IRQ/ DMC DMA read.

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Post by Sour » Tue May 19, 2020 7:43 pm

Bananmos wrote:
Sun May 10, 2020 9:05 am
Ah, I see. No worries about using a different operator if it makes things simpler. I'm happy to use something like "Y MOD 4", and keeping the widepsread % prefix for 6502 binary numbers is probably more important than the aesthetics of module
The modulo operator should be fixed as of the latest commit/appveyor builds (both this and binary notation still use %) - let me know if you still have issues with it.
za909 wrote:
Sat May 16, 2020 10:39 am
During my DPCM-PCM endeavors I really could've used some of the still hidden stats of the APU, namely the 8-bit DPCM buffer state, which if I am not mistaken is implemented as a bit shifter, so there is no separate bits remaining counter.
Thanks for the suggestion. At this point, I'm likely to eventually scrap the APU viewer and replace it by a much more versatile tool like the register viewer that exists in Mesen-S, which would easily allow me to show a lot more state (for the APU or other components, e.g maybe some specific common mappers, etc.), without it also being a nightmare in terms of UI/layout (doesn't help that Mono on Linux sizes everything differently a bit which makes this more painful still.) I'll keep this in mind for when I do replace the APU viewer, though.

Bananmos
Posts: 532
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Post by Bananmos » Sat Jun 27, 2020 5:38 pm

The modulo operator should be fixed as of the latest commit/appveyor builds (both this and binary notation still use %) - let me know if you still have issues with it.
Sorry for late reply... modulo operator works great for me now!

But there's a few other things that have been annoying me lately in the otherwise-awesome debugger:

1) It appears I cannot get local labels to work in Mesen's watch window. ca65 local labels use a @ prefix, and it looks like Mesen doesn't recognise these as they always come out as <invalid expression>. This means missing out on a lot of the potential of the variables watch window, as I need to keep entering and remembering the numerical address of variables instead.

2) Another problem with ca65 local vars is that the Mesen debugger's disassembly will frequently show the wrong version of a local variable. i.e., if you have one subroutineA declaring "@foo = TEMP" and subroutineB declaring "@bar = TEMP", then subroutine may end up showing an "sta @foo" in the disassembly where the source had "sta @bar". If it's not fixable, then I would actually prefer for the disassembly to just show the raw numerical values, as seeing the wrong variable name is quite distracting / confusing.

3) The reverse-debugging feature is often a life-saver, but I can't seem to get it to work reliably. Sometimes I'll click it and it'll backstep an instruction just as I expect. But other times, the click will take me as far back as the reset time. Do you know what might be causing this intermittent bug?

4) Speaking of the reversible debugging, it would also be awesome if there was a simple way to backtrack more than a single instruction, just like the forward debugging can run one scanline or one frame. The assert feature has been of great use to me, but I often need to backtrack for a long time to get to the root cause of the assert, because I can't find a way to execute backwards on a coarser granularity.

Lastly, just want to say a big thanks for all the improvements done so far to the best NES debugger there ever was! A lot of the more complicated coding I've done recently would have taken several days more of debugging effort without them :)

Bananmos
Posts: 532
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Post by Bananmos » Sun Jun 28, 2020 11:53 am

Oh, a while back you also asked me about how well the OAM corruption feature worked. I've just tried using it today, and had positive but still-kind-of-mixed results with it.

My sprite scaling code had introduced a regression in OAM corruption, and before fixing it the results on my NTSC NES and Mesen matched up pretty much perfectly. Have a look at this video which has my HiDef-NES and HDTV in the top part, with Mesen running on my laptop at the bottom:

https://photos.app.goo.gl/kVaU2bv8f469hNEJ8

I then used Mesen's event viewer to re-organise the writes to $2001, and quickly ended up with a version that worked in Mesen - but was still buggy on the real HW:

https://photos.app.goo.gl/wbYao2n5jYfbajfr9

Finally, after some more tweaking to have all the $2001 happen around dot 330 (which appears to only corrupt sprites 2-5), I got it looking flawless on both the HW and Mesen:

https://photos.app.goo.gl/C6pyoxe2DquSLpcW8

So looks like the OAM corruption emulation in Mesen might still need some tweaks. Nevertheless, it's already a good sanity check :)

Fiskbit
Posts: 200
Joined: Sat Nov 18, 2017 9:15 pm

Re: Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Post by Fiskbit » Sun Jun 28, 2020 2:56 pm

OAM corruption emulation in Mesen is known to be incomplete. We believe it's roughly accurate for the case where you turn rendering off mid-frame and turn it back on in vblank, but if you turn it off mid-frame somewhere around dots 65 to 256 and then you turn it back on mid-frame, there is additional corruption on some CPU/PPU alignments that is not understood well enough to emulate. I can't tell in your video exactly what's going on in the event viewer, so I'm not sure what the specifics of your case are. If you're not turning rendering on mid-frame, I'd be very interested in understanding why Mesen differs from hardware.

Edit: Looking closer at the videos, I see some tiles flashing lower on the screen which leads me to believe that you were indeed hitting the 65-256 issue; the emulated issue simply copies the contents of OAM row 0 into the victim row, while this unemulated issue causes some kind of data corruption of the victim row that results in tiles moving to unique positions. We were discussing this on the nesdev Discord not too long ago and I worked out that performing the write to disable rendering anywhere in the dot range 318-340 (as reported in the Mesen event viewer) should be safe regardless of when you reenable rendering. While this range hasn't been thoroughly tested, I didn't see any evidence of corruption there in my oam_flicker_test_reenable test ROM. I'm a little surprised that you're saying you see sprite corruption when disabling around dot 330, but since it sounds like it's only corrupting rows 1 and 2, perhaps you have enough variance in your timing that sometimes your write is landing as late as dot 3.

Bananmos
Posts: 532
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Post by Bananmos » Sun Jun 28, 2020 3:45 pm

Fiskbit wrote:
Sun Jun 28, 2020 2:56 pm
OAM corruption emulation in Mesen is known to be incomplete. We believe it's roughly accurate for the case where you turn rendering off mid-frame and turn it back on in vblank, but if you turn it off mid-frame somewhere around dots 65 to 256 and then you turn it back on mid-frame, there is additional corruption on some CPU/PPU alignments that is not understood well enough to emulate. I can't tell in your video exactly what's going on in the event viewer, so I'm not sure what the specifics of your case are. If you're not turning rendering on mid-frame, I'd be very interested in understanding why Mesen differs from hardware.

Edit: Looking closer at the videos, I see some tiles flashing lower on the screen which leads me to believe that you were indeed hitting the 65-256 issue; the emulated issue simply copies the contents of OAM row 0 into the victim row, while this unemulated issue causes some kind of data corruption of the victim row that results in tiles moving to unique positions. We were discussing this on the nesdev Discord not too long ago and I worked out that performing the write to disable rendering anywhere in the dot range 318-340 (as reported in the Mesen event viewer) should be safe regardless of when you reenable rendering. While this range hasn't been thoroughly tested, I didn't see any evidence of corruption there in my oam_flicker_test_reenable test ROM. I'm a little surprised that you're saying you see sprite corruption when disabling around dot 330, but since it sounds like it's only corrupting rows 1 and 2, perhaps you have enough variance in your timing that sometimes your write is landing as late as dot 3.
Exactly where can I find the oam_flicker_test_reenable ROM?

I'm equally surprised to hear the claim that there's a 100% safe area to enable / disable rendering, because when I tried this a few years back and determined that 330 was the sweet spot, there was still corruption on sprites 2-3 that I couldn't get rid of by any means, so I just determined that was an ok sacrifice for using forced blanking to get more VRAM bandwidth :)

This time around, it seems my code was a little bit more off and sprites 2-5 were affected - but I wasn't trying as hard as I simply wanted to get rid of the flicker in this test ROM.

If there is indeed a 100% safe enable/disable location to show all 64 sprites at arbitrary scanlines, I'd be really keen to use the technique! While sacrificing a few sprites isn't the end of the world it's always felt a bit inconvenient, especially as the issue doesn't even exist on PAL machines.

Fiskbit
Posts: 200
Joined: Sat Nov 18, 2017 9:15 pm

Re: Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Post by Fiskbit » Sun Jun 28, 2020 4:21 pm

You can find oam_flicker_test.nes and oam_flicker_test_reenable.nes in this and the following post. Assuming the safe region is indeed safe, a problem with it is that it's only just barely large enough to fit the variance in timing if you use IRQs, so you have to be very precise. Micro Machines is an example of a game that turns rendering off and on mid-frame in the safe region without encountering any corruption that I'm aware of.

I haven't done any testing on PAL, so this is the first I've heard that the problem doesn't occur on PAL PPUs, but I'm not surprised. Also, this issue was actually introduced in later NTSC PPUs, though I haven't found yet exactly where it was introduced. I know E-0 and later do have it, and A and B do not. My guess is that it was introduced in either E-0 or D-0, and that D and earlier don't have it.

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Post by Sour » Tue Jun 30, 2020 1:33 pm

Bananmos wrote:
Sat Jun 27, 2020 5:38 pm
But 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.

tepples
Posts: 22160
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Post by tepples » Wed Jul 01, 2020 2:20 pm

Sour wrote:
Tue Jun 30, 2020 1:33 pm
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)
Compare Game Boy, where BGB can recognize which scope a label is under. For example, 144p Test Suite, it gives the name memcpy.loop for a cheap local label .loop belonging to the label memcpy. Under ca65, you could display memcpy@chrloop if it's defined as a cheap local label. Or, if defined in a .proc (as seen in the tech demo of the ca83 macro pack), you'd get memcpy::loop.
Sour wrote:
Tue Jun 30, 2020 1:33 pm
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.
Per the ca65 Users Guide, a symbol defined with := is marked as a label.

Bananmos
Posts: 532
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Post by Bananmos » Thu Jul 02, 2020 4:22 am

Sour wrote:
Tue Jun 30, 2020 1:33 pm
Bananmos wrote:
Sat Jun 27, 2020 5:38 pm
But 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)
Hmm, didn't realise local labels were such a hairy issue.

I think Tepples hint about just concatenating local labels top top-level ones might be the best starting point to get around the complexity. And I could probably add such a concatenation step to my build scripts that just keeps track of the current label top-level label (.proc or not) and renames all the labels in the source file as per Tepples suggestion.

But I'd like to do it with the end-goal of it potentially being a usable solution to incorporate in Mesen's debugger at some point. Is there anything else I might have overlooked that would make it infeasible?

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.
I see. Well, even with the limitations / bugs it's a very useful feature to have when debugging, and I honestly would be a much happier man if there was just *some* way of stepping back at a coarser granularity than a single cycle, no matter how crude. Just a "step ~100 cycles backwards" would be a huge improvement over having to hold the button for minutes, just to find out what happened before a long loop.

Oh and btw, I only now realized you've got a "buymeacoffee" account in addition to your Patreon. Do you prefer one donation mechanism over the other? :)

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Post by Sour » Thu Jul 02, 2020 8:32 am

Bananmos wrote:
Thu Jul 02, 2020 4:22 am
I think Tepples hint about just concatenating local labels top top-level ones might be the best starting point to get around the complexity.
This isn't enough to make it work properly, unfortunately - even if you had 2 labels with unique names, e.g: "memcpy@tmpVar" and "clear@tmpVar", labels that point to the same address in memory are not allowed (because it's impossible for mesen's disassembler to select which label to show, unless it knows the scope where each label is used.) So while appending the scope's name to the label name might fix some of the duplicate name issues (but this scenario is already handled by appending a unique number to the label, so it wouldn't change a whole lot), it doesn't solve the case where there are multiple labels pointing to the same address (e.g temporary variables in zero page)

So it comes back to needing to know the scope - but implementing this requires:
-Figuring out an (intuitive) UI to display/edit the scope for each label (or hiding all of this information and making it CA65-specific but that's not very useful for anybody else that would want to use this feature..)
-Altering mlb label files to contain this information
-Changing the disassembler, trace logger, etc. to be able to select which label to display based on the current context, etc.

I'm probably forgetting some things, but the UI/label files are the most problematic here - and I'm slightly concerned about making the UI/file format more complex for this somewhat advanced use case (although I realize this is fairly common.) And it would end up being ca65-specific in terms of usage, because asm6f doesn't support this, and nobody is going to take the time to manually add label scopes in the UI, either, I doubt...
Bananmos wrote:
Thu Jul 02, 2020 4:22 am
if there was just *some* way of stepping back at a coarser granularity than a single cycle, no matter how crude. Just a "step ~100 cycles backwards" would be a huge improvement
Ironically, even stepping 100 instructions back is more complex than it sounds, because I have no idea what the exact cycle count was 100 instructions ago. I'll add it to the list of requests, but may be a while before I get around to it as I'm still in the middle of attempting to wrap up super game boy support on Mesen-S.

Also, in case it's useful - you can also use the history viewer to reload a save state at any point, there's a different save state that can be loaded for every 1 second of execution, but might be useful in some scenarios?

RE: Patreon vs BuyMeACoffee, BuyMeACoffee is essentially the "old" donation page which I stopped using when I realized it didn't even allow people to use paypal and the like. It's still there as an option in case people prefer using it, but I think basically nobody has used it in the past year now :p Either is fine really, feel free to use whichever you prefer - thanks for the support!

Bananmos
Posts: 532
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Post by Bananmos » Fri Jul 03, 2020 10:00 am

Sour wrote:
Thu Jul 02, 2020 8:32 am
Bananmos wrote:
Thu Jul 02, 2020 4:22 am
I think Tepples hint about just concatenating local labels top top-level ones might be the best starting point to get around the complexity.
This isn't enough to make it work properly, unfortunately [...]
Ah, sounds like it is far off into the future then :(

Given this limitation, would it be possible to at least add a comment field to the watch window? Then I can at least remember what variable a numerical value added to the watch window actually represents by typing it in there, and having it right there on the same line does beat doing the same mapping with a sheet of paper on the side. And I guess the comment can be used for other potentially useful things, independent of whether you use ca65 or not :)
Also, in case it's useful - you can also use the history viewer to reload a save state at any point, there's a different save state that can be loaded for every 1 second of execution, but might be useful in some scenarios?
Thanks, didn't know that. But unfortunately, 1 second is probably *too* large a granularity. To use the reverse debugging for back-tracking to an error after the fact, it's really 1 instruction and approximately-a-scanline-worth-of-instructions that are the most useful. With the latter really being needed just because cycle-by-cycle-reversal is too time-consuming to sit through.

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Post by Sour » Sun Jul 05, 2020 1:39 pm

Bananmos wrote:
Fri Jul 03, 2020 10:00 am
Given this limitation, would it be possible to at least add a comment field to the watch window?
If that's the main functionality you are looking for (e.g being able to put it in the watch, vs having it display properly in the disassembly window), this is probably easier to fix. I can probably alter the label code to allow different labels to point to the same memory address, without any concept of scope, but this would at least let you use the watch normally. This + adding the name of the ca65 scope to the label when importing might fix a decent portion of the issues. e.g you could have "scope1_foo" and "scope2_bar" both pointing to address $123, and then use "scope1_foo" or "scope2_bar" as expressions in the watch list (which would always give an identical value). At this point the only scope-related issue would be the disassembly view not always displaying the right label for the address, but everything else would technically be working as expected, I think?

Bananmos
Posts: 532
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: Mesen Debugger - Feedback/Feature Requests? (2018 edition)

Post by Bananmos » Sun Jul 05, 2020 3:50 pm

Sour wrote:
Sun Jul 05, 2020 1:39 pm
Bananmos wrote:
Fri Jul 03, 2020 10:00 am
Given this limitation, would it be possible to at least add a comment field to the watch window?
If that's the main functionality you are looking for (e.g being able to put it in the watch, vs having it display properly in the disassembly window), this is probably easier to fix. I can probably alter the label code to allow different labels to point to the same memory address, without any concept of scope, but this would at least let you use the watch normally. This + adding the name of the ca65 scope to the label when importing might fix a decent portion of the issues. e.g you could have "scope1_foo" and "scope2_bar" both pointing to address $123, and then use "scope1_foo" or "scope2_bar" as expressions in the watch list (which would always give an identical value). At this point the only scope-related issue would be the disassembly view not always displaying the right label for the address, but everything else would technically be working as expected, I think?
Yeah, the watch is indeed the most important thing of the two! It'd be great if there was some way to have the local labels work there. Your proposed work-around sounds just like that.

My main grit with the disassembly was actually just that the labels in it become a disservice as soon as cheap local labels are used. If there's a way to totally mask away any named labels that start with '@' in the disassembly (i.e., just use plain-old-addresses for those), then that's another good improvement for my sanity ;) But I have found myself to use the excellent source-level debugging more and more anyway, so it's of much less importance compared to getting the watch window working.

Post Reply