Roadmap: Disassembly View Feature

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:

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

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

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

Thank you.

Yue (Felix) Huang (@yuehuang010)

Yue (Felix) Huang (@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 Benjamin Pasero (@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 Logan Ramos (@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 Benjamin Pasero (@bpasero) Matt Bierner (@mjbvz) Logan Ramos (@lramos15) for custom editor thoughts

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 {

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

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>`;
  }
};

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.

Isidor Nikolic (@isidorn)

Isidor Nikolic (@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 Logan Ramos (@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

Logan Ramos (@lramos15)

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 Logan Ramos (@lramos15) faced when doing the hex editor

fyi João Moreno (@joaomoreno)

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.

Matt Bierner (@mjbvz)

Matt Bierner (@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?

Got it. I misunderstood.

Yue (Felix) Huang (@yuehuang010)

Yue (Felix) Huang (@yuehuang010) context keys should just work based on focus, you should not need to manualy set and unset them if they are only related to focus.
Can you please explain what context you would like to have and I can provide suggestions on how to achieve that? One that is active only when the focus is in the Disassembly View? Or something else?

Disassembly View Overview (Insiders) - PR #125737

Check if debugger supports "supportsDisassembleRequest", then while debugging, right click on a source code to see "Open Disassembly View".

A Disassembly View editor will appear with each line representing each instruction.

In the Disassembly View, you can:

Scroll up or down to see more instructions. Should be able to scroll without limit.
The yellow arrow marker represent current instruction. Use F10/F11 to step in or step over current instruction.
A red dot will appear while hovering over the left "gutter". Click to set or unset breakpoint.

Thanks.

Nice!
It'd be great if the 2 views were merged, showing the original source code inline with the asm like VS does iirc and objdump.

Nice!
It'd be great if the 2 views were merged, showing the original source code inline with the asm like VS does iirc and objdump.

The initial insider is focused getting core functions up and running. Syntax color and Source code next on the todo list.

Please find additional discussions in the associated PR.

I've upgraded Mock Debug to support the "Disassembly View" feature:

Could this extension add an address searcher like Visual Studio?

Navigation Menu

Repository navigation

Roadmap: Disassembly View Feature #124163

43 remaining items

Disassembly View Overview (Insiders) - PR #125737

In the Disassembly View, you can:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Roadmap: Disassembly View Feature #124163

Description

Activity

isidorn commented on May 19, 2021

bpasero commented on May 19, 2021

isidorn commented on May 19, 2021

yuehuang010 commented on May 19, 2021

xisui-MSFT commented on May 19, 2021

mjbvz commented on May 19, 2021

isidorn commented on May 19, 2021

lramos15 commented on May 19, 2021

xisui-MSFT commented on May 19, 2021

43 remaining items

bobbrow commented on Jun 23, 2021

isidorn commented on Jun 24, 2021

yuehuang010 commented on Jul 7, 2021

Disassembly View Overview (Insiders) - PR #125737

In the Disassembly View, you can:

Trass3r commented on Jul 7, 2021

yuehuang010 commented on Jul 7, 2021

weinand commented on Jul 22, 2021

learnpythontheew commented on Sep 2, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions