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

rox_midge
Posts: 89
Joined: Mon Sep 19, 2005 11:51 am

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

Post by rox_midge » Sun Jul 05, 2020 6:43 pm

One thing that would save me a bunch of time would be if breakpoints could be based on the symbol name instead of the absolute address. While debugging yesterday and today, I kept having to reconfigure my breakpoints because the address of the function I wanted to break on kept changing. The debugger does show the symbol name if it has a zero offset, but the breakpoint is actually set to the absolute address.

User avatar
Controllerhead
Posts: 165
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

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

Post by Controllerhead » Sun Jul 05, 2020 11:14 pm

rox_midge wrote:
Sun Jul 05, 2020 6:43 pm
One thing that would save me a bunch of time would be if breakpoints could be based on the symbol name instead of the absolute address. While debugging yesterday and today, I kept having to reconfigure my breakpoints because the address of the function I wanted to break on kept changing. The debugger does show the symbol name if it has a zero offset, but the breakpoint is actually set to the absolute address.
I'll second that.

A way to reload a label file while a game is running if ? it isn't too much to ask : it can't be done already ; would be super helpful as well. A setLabelAddress() in the Lua API to match the getLabelAddress() as well as a loadLabelFile() would be godlike =)

I really do appreciate and utilize all of your hard work already! Thank you!

EDIT: You can indeed reset and reload labels in the debugger. File -> Workspace -> Reset / Import Labels / Other Options
Image

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

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

Post by Sour » Mon Jul 06, 2020 8:26 pm

Bananmos wrote:
Sun Jul 05, 2020 3:50 pm
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)
This is a bit tricky, since the labels are used by both the disassembly and the watch window (among other things), so removing the label for one, will also remove it for the other. Hiding them just based on the starting character is something I'd prefer to avoid, since it would be an assembler-specific thing (e.g nesasm appears to use a dot to denote local labels.), and would require an option to not do this automatically, etc. I'd rather not add too much logic to patch out the issue when the real problem is really that scoped labels are not supported.
rox_midge wrote:
Sun Jul 05, 2020 6:43 pm
One thing that would save me a bunch of time would be if breakpoints could be based on the symbol name instead of the absolute address.
So I did some quick tinkering and had a working solution for this... except then I realized it would only work on a breakpoint that matches a label, meaning any breakpoint that's not on a label would still be lost/incorrect after rebuilding, which isn't really great and just means it still won't do what you'd hope most of the time.

I'm not really seeing a reasonable way of getting this done properly that would both be simple and work for the majority of cases - most scenarios would require analyzing the disassembled code to try and find the matching line (but that's not possible because Mesen no longer has access to the "old" version of the rom by the time this occurs), etc. Also thought about using an offset to the closest label, but that would also be tricky, and would end up with breakpoints in-between instructions often, etc. (and fixing that would again require analyzing the disassembly to move the breakpoint to the nearest instruction, etc.) It's possible to do this, but it's a lot of effort, as is (esp. due to how the disassembly is a C++ core functionality while the label management is mostly UI-side, etc.) I'll keep it in mind and try and see if I think of a better/simpler solution for this.
Controllerhead wrote:
Sun Jul 05, 2020 11:14 pm
A setLabelAddress() in the Lua API to match the getLabelAddress() as well as a loadLabelFile() would be godlike
Unfortunately, like I kind of mentioned above, the labels are managed by the UI and the C++ core only receives a list of them, but does not have the ability to modify them or load label files, etc. So adding this functionality in the Lua API would require a lot of pretty hacky code for the Lua to tell the UI to load label files or alter/add/etc labels - I think that's a can of worms I'd rather not open at the moment.

Also, FYI, Mesen should be auto-reloading .dbg or .mlb files whenever you reload the rom (assuming you have the option to auto-load dbg/mlb files turned on), so in most scenarios, you shouldn't need to manually reload the labels.

rox_midge
Posts: 89
Joined: Mon Sep 19, 2005 11:51 am

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

Post by rox_midge » Tue Jul 07, 2020 7:04 am

Sour wrote:
Mon Jul 06, 2020 8:26 pm
So I did some quick tinkering and had a working solution for this... except then I realized it would only work on a breakpoint that matches a label, meaning any breakpoint that's not on a label would still be lost/incorrect after rebuilding, which isn't really great and just means it still won't do what you'd hope most of the time.
I can't speak for anyone else, but I'd be 100% fine with this caveat. The breakpoint display in the debugger only shows the symbol name if the breakpoint is directly on a symbol anyway. If I needed a breakpoint that wasn't directly on a symbol, I can just export a symbol wherever I want the breakpoint to be.

I'm sure you hear this a lot, but thanks for all your work on Mesen - it's like night and day compared to the way I was trying to build and test my game before!

User avatar
Controllerhead
Posts: 165
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

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

Post by Controllerhead » Tue Jul 07, 2020 8:37 am

rox_midge wrote:
Tue Jul 07, 2020 7:04 am
Sour wrote:
Mon Jul 06, 2020 8:26 pm
I realized it would only work on a breakpoint that matches a label, meaning any breakpoint that's not on a label would still be lost/incorrect after rebuilding
I can't speak for anyone else, but I'd be 100% fine with this caveat.
Oh man, that is clearly a user error. If it were me those unlabeled breakpoints would be long gone baby. You're too kind =p

Although, for hacking / stepping through commercial games that do not have labels, this behavior could certainly be problematic.

I vote for keeping the current behavior as default, and putting in your breakpoint label matching behavior as an option.

Image
Image

rox_midge
Posts: 89
Joined: Mon Sep 19, 2005 11:51 am

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

Post by rox_midge » Tue Jul 07, 2020 12:19 pm

I think I'd prefer it if there were a different breakpoint type for symbolic breakpoints:
Annotation 2020-07-07 141649.png
Although this would require that the UI allow the symbol name to be edited instead of just the address:
Annotation 2020-07-07 141845.png

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 10, 2020 3:51 am

Two other minor feature requests:

1) I like how the watch allows decimal, hex and binary display format. But I noticed it's a global setting for all variables in the watch, whereas sometimes it's quite useful to different variables in different formats.

Would it be possible to support this? Could be either through the menu, or just some name syntax to override the default display format.

2) I am currently working on some image scaling code that copies CHR data into different banks, and realised that once my code switches the CHR bank, there's no way to make the PPU viewer display the nametable data with the original correct CHR bank whilst my program is paused in the debugger.

Would it be possible to duplicate the "CHR Selection" menu from the CHR Viewer into the Nametable Viewer as well, so I could force the Nametable Viewer to show the original data?

User avatar
minion
Posts: 2
Joined: Wed Aug 19, 2020 8:41 am

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

Post by minion » Thu Aug 20, 2020 6:19 pm

Just wanted to drop a post here in case others had a similar request - I filed a Github issue yesterday asking for trace logging to log memory values at the time of execution, similar to FCEUX: https://github.com/SourMesen/Mesen/issues/869

Apologies if someone else in this thread has already posted the request. I wasn't getting much from the search and this thread is so long now! :D If I can get this feature, I think I can finally ditch FCEUX!

User avatar
Banshaku
Posts: 2393
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

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

Post by Banshaku » Thu Aug 20, 2020 6:56 pm

@minion

It may take time before this request will be done in mesen since sour as left the scene. So unless he come back or someone else take mesen and continue his project then it may never happen unfortunately.

User avatar
minion
Posts: 2
Joined: Wed Aug 19, 2020 8:41 am

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

Post by minion » Fri Aug 21, 2020 1:12 am

Banshaku wrote:
Thu Aug 20, 2020 6:56 pm
@minion

It may take time before this request will be done in mesen since sour as left the scene. So unless he come back or someone else take mesen and continue his project then it may never happen unfortunately.
Ah, good to know. I have the latest source pulled down but I'm not a big fan of c#. Maybe I'll hack on it a bit and see if I get anywhere. People needing to move on from OSS projects is just a fact of life, what we already have is such a fabulous toolkit, I certainly don't want to complain!

Post Reply