Additional debug output panels

[TurkeyMan]

It's hard to debug (native code) without:

• Raw memory view
• Register view
• Disassembly view (while stepping)

Please make these panes available, or make it possible for plugins to implement them at separate dock-able panes?

[weinand]

@TurkeyMan what debug extension are you referring to?

[TurkeyMan]

This is the most mature one so far: https://github.com/WebFreak001/code-debug
With respect to my issue, I'm sure the plugin is limited by the available UI and debug 'features' that it can support and populate with data. Memory view and registers are easy to populate with data from the debug engines. Disassembly might be some work on both sides, but it's very important.

[TurkeyMan]

Naturally, the obvious reference point for disassembly/interleaved-source view look+feel is VS.
A major bonus on top of VS would be the ability for the debug engine to annotate each line of assembly with some additional data, like opcode timings/latency, etc, so debug engine can help identify pipeline stalls and such.
This may not require any support from vscode, but just something to keep in mind.

[TurkeyMan]

I'll add one more note on a quality implementation of a disassembly window; the best disassembly viewers are able to store metadata about the sources and destination for each opcode, and also jump targets. The value of this, is that when you click on a line of the code, the IDE is able to highlight the sequence of registers as they flow from one operation to the next. It's also useful to highlight/isolate separate sequences, so you can follow the flow of a particular sequence of operations, since in optimised code, it is typical that many sequences of code are all interleaved, and they can only be followed by analysing the inputs and outputs of each opcode and how they flow into eachother.

I raise this because it would be useful for the debug API to accept this information from the debug engine, and then the IDE/UI may do something to visualise the data if it likes. If the API is available such that the debug engine is able to provide this information, then it doesn't hurt :)

[weinand]

@TurkeyMan you do not have to convince me how important a disassembly view – or the other views you've mentioned – are for specific debugging scenarios. I fully agree.

However, we will not make a "disassembly view" (or any other debugger specific view) part of the VS Code debugger architecture. Instead we will provide architecture and API so that others can add these things.

[TurkeyMan]

Sounds good.
I suppose this means that the UI layout will become somewhat more flexible in that case, if it is to support plugging in new panels?
This will be a very welcome change itself, since my main complaint with code is the general inflexibility of the workspace layout.
Looking forward to it!

[erichiller]

Ability to view variable memory consumed is exactly what I'm looking for.

[tim37021]

@erichiller +1
I wish at least the plugin supports entering gdb commands in debug terminal.

[weinand]

@tim37021 support for entering gdb commands in debug terminal is totally unrelated to this request. Please file this against the gdb debug extension. VS Code has no builtin "gdb" but the architecture already supports REPL via the debug console.

[donfiguerres]

vscode-cpptools currently has an open issue to address this one microsoft/vscode-cpptools#941

[weinand]

Since July 2017 VS Code Node Debugging has a "Loaded Scripts View" which has been implemented solely as an extension contribution.
See https://code.visualstudio.com/updates/v1_15#_loaded-scripts-explorer

This proves that debug extensions are able to contribute custom views.