Roadmap: Disassembly View Feature

[yuehuang010]

Hi Team, C++ Extension is interested in developing an Disassembly View to represent the added interface in DAP (https://microsoft.github.io/debug-adapter-protocol/specification#Requests_Disassemble). Below is a quick bullet points of the set of features we would like to see.

To contrast, Visual Studio Disassembly Window is shown in the screenshot below:

The view should include:

1. Address, Assembly Code in Byte/Hex, Assembly Instruction, Data of related memory and registers (All information is provided by DAP and debugger.)
2. Functions Marker if available.
3. Interleave with source code (if present)
4. Breakpoints gutter to set and remove BP.

In additional to displaying the data, users could also interact with the view by:

1. Setting Breakpoints at the per instruction and Breakpoints should appear in the breakpoint list.
2. Stepping per instruction. Controls should flow nicely existing debug step in/out.
3. Scrolling Up and Down will load instructions above and below.
4. Need a way to toggle Hex view for values.

Thank you.

[isidorn]

@yuehuang010 thanks a lot for creating this issue

After some discussions with my fellow colleagues it feels like the best path forward would be to implement a custom editor internally. This custom editor would listen to DAP requests and based on that show the appropriate data.

A good example of a custom editor is the textAreaEditor implement by @bpasero as an example in his branch here. Though the memory editor would be read only so it would not require all the code for dealing with working copies. This custom memory editor would appear pinned while debugging and could maybe automatically go away once debugging is done.

If we were to introduce a custom memory editor I think a good place for it to live would be under src/vs/workbench/contrib/debug/browser/. It could depend on the IDebugService and from the service get all the needed data and pass breakpoints to it.

Maybe a Hex view could also be a good inspiration for a virtual editor. Though I know it is done from an extension. Maybe @lramos15 has a good pointer

Once we figure out how and where to do this, we can discuss how exactly it would look and behave. Maybe we do a 30 min meeting some time start of next week?

fyi @bpasero @mjbvz @lramos15 for custom editor thoughts

[bpasero]

Maybe an easier example is to look at an existing readonly editor such as the "Runtime Extensions" editor:

vscode/src/vs/workbench/contrib/extensions/browser/abstractRuntimeExtensionsEditor.ts

Line 65 in 8c5490f

export abstract class AbstractRuntimeExtensionsEditor extends EditorPane {

[isidorn]

This RuntimeExtensionsEditor is used when a user does F1 > show running extensions if you want to check it out.

[yuehuang010]

I was playing around with HTML onscroll event. Adding more "lines" to the body will extend the text document, which indirectly un-bottom's scroll bar. This would give it an infinite scrolling feel. Flipping the logic upwards scrolling would work too.

window.onscroll = function(ev) {
  if ((window.innerHeight + window.scrollY) >= document.body.offsetHeight) {
    document.body.innerHTML += `<p>${window.innerHeight} + ${window.scrollY} >= ${document.body.offsetHeight}</p><br>`;
  }
};

[xisui-MSFT]

Simply using an onscroll event would likely cause performance issue at some point. Scroll itself had never been an issue for us. Our major issues are the problems associated with scrolling, including but not limited to:

• How to create + destroy lines and margin overlays (rerender) dynamically.
• How to keep users selections.
• Corner cases related to font and foreign languages.

Using internal vs code stuff certainly helps us, as the main editor resolves these issues very well, but it does all the calculations based on line number. We need to settle a way to do layout without using line number. There are several possible ways, depending on how generic you would like this editor to be.

[mjbvz]

@isidorn There are two routes you could go with a custom editor:

• Create an internal custom editor (such as AbstractRuntimeExtensionsEditor). These are only possible to create internally in VS Code and cannot be created by extensions

• Create a webview based custom editor. These are what the Custom Editor API lets extensions build. The hex editor extension uses these

I suggest looking into a non-webview based custom editor first since that would let you use all of our internal classes, such as the ListView. It is also easier to make them feel like part of VS Code compared to a webview

You can also check in with @lramos15 about some of the challenges he faced implementing the hex editor, specifically some of the work he did so that the hex editor can display large files and smoothly scroll through them

[isidorn]

Yeah ListView might be a good way to go for the memory view, as it would give us virtualisation for free.
Interested to hear what @lramos15 faced when doing the hex editor

fyi @joaomoreno

[lramos15]

Yeah I don't know how we feel about a one off solution that belongs to an external extension living within VS Code core. Although the implementation details are a lot easier when having access to VS Code internals.

Here are a few challenges I came across with the hex editor

• Extension is responsible for all styling and implementation. Things like the find widget I had to restyle and remake and the experience doesn't match 100% to that of VS Code
• Own implementation of virtualized scrolling. Using a JS framework might help in this case as they have third party modules for that, but I kept the hex editor without virtual scrolling and the scrolling was very difficult to implement and still not correct for things like trackpads.
• Webview <-> Ext host communication bottlenecks meant proper packeting had to be implemented as sending too much data could hang the webview or crash the ext host.
• Accessibility support is up to the extension author and therefore might not align with VS Code.
• Extension is limited by available APIs (we could always expose more if necessary)

Overall making a custom editor extension isn't easy and those were my main challenges. I'm not sure what the challenges would be for an internal custom editor.

[xisui-MSFT]

@mjbvz I'm not sure if we can use an custom editor. Two features are currently blocking us from using a custom editor:

• Breakpoints that are not associated with line numbers.
• It should be able to (act like) scrolling infinitely. The hex editor seems to depend on the file size for display. I'm not sure if that's possible for disassembly. Also the "file size" may change based users' config such as showing source code.

Any suggestions?