Feature Request: Help. How to integrate this into a debugger

[haneefdm]

First of all. Wow. Nice.

I am a maintainer of a C/C++ debugger within VSCode for ARM devices. I would love to use this editor (just the viewer part). I also contribute to VSCode core debugger sometimes where this idea can also be helpful

I want to use this extension as a memory viewer while debugging. I currently use a URI that updates every time the debugger pauses (breakpoint, step, next, etc.). IE, the file is not on disk but is dynamic. I have an okay memory viewer but this is much better. Is it possible to extend this extension or have an API for me to reuse this code to display dynamic content? I bet every debugger would want that, at least for lower-level languages.

It would be a shame for me to duplicate the work you have done or make a custom copy of it.

I will do the work and submit PRs here. Any pointers for me on how to approach this and make it a general-purpose feature for other debuggers. As far as I know, one extension can't use another extension directly. Could I import it as a node module? Could we have events that could create/update the document?

Here is my project. https://github.com/Marus/cortex-debug

I bet my users would be thrilled by it.

[connor4312]

I think the best solution here would be to have some custom bits in the debug adapter to, for example:

1. Have some "inspect memory" command registered for your debug adapter that that copies the relevant portions of memory to the file. (Or toggles copying, if you wanted it on each step)
2. Uses the vscode.openWith API to open the hex editor / default binary editor on that file
3. If you want to allow editing, watch for when that file is saved to update memory.

With a little more work, you can avoid the filesystem by creating a virtual document (which allows read-only documents) or your own filesystem provider.

This can be accomplished by sending your own custom DAP messages, via the DebugSession.customRequest message / vscode.debug.onDidReceiveDebugSessionCustomEvent.

cc @lramos15

[lramos15]

@haneefdm I'm not nearly as well versed in debuggers as @connor4312 is so I'll defer to his response. I think there's not much work that needs to be done on the hex editor end, just opening the file in read only mode which I would be happy to investigate for you. I would say try to follow what @connor4312 says and post back here if it's not working for you.

You can use the extensionDependencies attribute to ensure that this extension is installed with your debugger.

[haneefdm]

First, I am so very hopeful and happy.

Thank you @lramos15, for the extensionDependencies idea. I will do it

Thank you @connor4312, for the suggestions, that is where I was headed (for now, looking into virtual documents). I got it working, kinda. We already use debugger custom requests for a ton of things. But a couple of issues

• Wish I could pass an argument that gave an address offset. I attached two screenshots below and that is the main (but important) difference. Anything you advise here would be awesome.

                const fsURI = vscode.Uri.file(filePath);
                fs.writeFileSync(filePath, Uint8Array.from(data.bytes));
                vscode.commands.executeCommand("vscode.openWith", fsURI, "hexEditor.hexedit");

• I am hoping if the file changes on disk, the hexEditor window will auto update/revert
• For now, I want to force read-only mode. Once editing is enabled, then there is a bit of work to do and confusion (two versions of the truth). A virtual document may fix that and more performant, digging into it
• Using less white space for "Decoded text" maybe a good idea. Also, we do 8-bit decoding which is not a big deal but Europeans love it :-)
• I need to figure out how to open and editor have it stick. Notice the one I invoked with hexEditor is in Italics, meaning it will disappear when another temporary one is opened. I am sure there is a way.

Sorry for the dark theme. This screenshot is how I got to open the hexEditor

And here is ours in VSCode...

[lramos15]

@haneefdm I'll try to address all your issues, let me know if I don't hit anything.

• Currently the offset will always start at zero and there is no parameter to change that. This would involve implementing an API that allows you to open at a certain offset
• The hexeditor currently doesn't have a filewatcher therefore if the file changes on disk it will not change. This is something that I hope to add shortly
• Currently no planned support for these yet as major things like search need to be worked on first. If you would like to implement a setting which you can modify these values I would be happy to merge your PR
• I believe this is just a setting in the editor "workbench.editor.enablePreview": false should cause tabs to be not in preview mode. I don't know of any way to specify opening a tab not as preview. Maybe @mjbvz can hop in and provide some input as well.

[mjbvz]

The vscode.open and vscode.openWith commands both take a viewColumn or a vscode.TextDocumentShowOptions as one of their arguments:

https://github.com/microsoft/vscode/blob/748fc4021a10d789c2f1e9927db05dcd75ead02e/src/vs/workbench/api/common/apiCommands.ts#L114

You should be able to pass { preview: false } in these options

[haneefdm]

@mjbvz Thank you. That works. I can open in the non-preview mode now.

vscode.commands.executeCommand("vscode.openWith", fsURI, "hexEditor.hexedit", { preview: false });

@lramos15 Thank you. Yes, a file watcher is going to be important. Every time a user single steps, the file will get updated. It is also similar to revert (#55) but the trigger is different. If I can help, I will submit a PR. I see it is on your TODO list but, if you can send me a couple of pointers I can be on my way.

Yeah, I don't know what to do with the start-address. Normally a user asks for only a certain portion of his overall (virtual/physical) memory. To truly be general-purpose, we may also have to support 64-bit addresses which is beyond my scope and of javascript limitations. Baby steps

Appreciate all the quick help. If all of this works out, I will summarize later for any debugger to use.

[lramos15]

@haneefdm

If you're interested in doing the offset work is to have the extension host (the files in the src folder) parse a query string in the uri such as ?offset=10 or whatever and then pass that into the constructor on the webview side https://github.com/microsoft/vscode-hexeditor/blob/master/media/virtualDocument.ts
You can then have the memory offset function use that to start at whatever you provided instead of zero.

64 Bit addressing would be possible with javascripts new support for BigInt, but you would have to rewrite a lot of code for thatl

Let me know if you have any other questions!

[haneefdm]

Yes, @lramos15 thanks. Looks easy enough. I will do it attempt to create the offset feature over the weekend

[lramos15]

@haneefdm File watching is now in master so you would just need to add a readonly mode and the offset uri to do everything you want

[haneefdm]

@lramos15 Oh thank you. I already finished the offset URI stuff and it is working well from my debugger. I will merge with your changes, test, and submit a PR.

[lramos15]

@haneefdm Need any help? I'm ready to close this issue. If you want you can make another feature request for readonly, but it sounds like everything is working for you

[haneefdm]

Yes, I can close this issue. I will do a PR over the weekend. Thanks so much for everything.

[haneefdm]

I just made a PR over the weekend #170