You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Feature Request] Memory viewer when debugging #509
Could you please add a memory browsing window to enable viewing of memory contents when debugging with gdb? It would also be great if the contents of watch variables / pointer locations could be easily shown in the memory browsing window (e.g. context-sensitive menu with 'View memory here').
This is a standard feature I look for in any debug GUI. It is extremely helpful to observe the data structure's memory as the code executes to get a full understanding of the system.
I hope this can be prioritized and implemented in a milestone soon
Reacted by Tim Bienias, Thomas Brüggemann, yh-sb, Dylan Tackoor, Ryan Erickson, Matt Thomas, Srijan Kumar Sharma, Davids Paskevics, substrateit, Alexandros Papadopoulos and 12 more
Reacted by Davids Paskevics, substrateit, Coconop, Stuart Thompson, Danyil Diabin, nilchu, KaiN, TR Lim, Armando Martín, vitordeoliveirafetchly and 1 more
This would be a fantastic feature. This is the one reason I still run my code via gdb or lldb (depending upon which machine I'm working on) at the terminal instead of via vscode. Running exec x/ commands in the VSCode terminal just isn't an equivalent.
Reacted by Danyil Diabin, nilchu, Carlos Pérez Alonso, KaiN, TR Lim, diy1982 and Stefan Radulescu
Please add this to the roadmap! That's a standard feature to debug in embedded systems with gdb. When developing my projects with VSCode, I still need to run eclipse in parallel for debugging because of this missing feature.
Reacted by Krzysztof, KaiN, Trass3r, TR Lim, Davids Paskevics, Armando Martín, pitris90, Maxim Snesarev, Tarang Janawalkar, Michal Bielecki and 1 more
I might as well not use vscode and use visual studio instead . . . pretty disappointing.
I heard similar views when searching for a way of profiling, with many referring to visual studio 😕
Ran into the same problem. For others who are stuck here: I am using a program called "Cheat Engine" in the meantime to look at disassembly and memory. It can connect to a running process and has a nice memory and disassembly. I copy the memory addresses from my VS Code debugging session over and can look at the memory (Ctr+G to jump to address).
Reacted by Philip, Edward Boggis-Rolfe, Ryan Thomas Lynch and ChenWeiNi
However, I'm currently stuck at getting information about the different Debug Session events like "pause". As this is my first every development with VSCode and its extensions, I don't have a perfect overview of everything. But the basic visualization is done and reading the memory is already supported by the underlying Debug Adapter Protocol.
Yes, we are actively working on supporting DAP readMemory and writeMemory in VS Code core. This was put on pause last month for our housekeeping iteration, but will resume next week. Active development is mostly happening in the hex editor to support arbitrarily large files via a streaming model, which will be used support for program memory. readMemory is likely land in the November iteration.
Why this has been closed? the disassembly window is not the same as a Memory View window. And the hex editor can only open files, not the debugging memory with specific address.
Why this has been closed? the disassembly window is not the same as a Memory View window. And the hex editor can only open files, not the debugging memory with specific address.
It is there, but has been implemented in an annoying and arbitrarily limited way. You are expected to hover over a variable in the locals section of the debugger side bar and click the hex icon. This opens up the hex editor to view the memory at the address pointed to by the local variable.
There is still no way to view any memory address. If you want to view any memory, you have to have a local pointer variable to it. You can't even view memory at addresses in registers.
Reacted by Walter Gray, Stefan Jensen and Veijo Pesonen
Connor Peet (@connor4312) My extension uses the "readMemory" and "writeMemory" DAP messages. So, it should work with any language implementation that supports those DAP messages.
Activity
zhelnio commentedon Feb 18, 2017
I'm also waiting for this. The small workaround to watch one addr is to define memory pointer and add it to watching values. This is working for me.
hoffmael commentedon Aug 28, 2018
This is a standard feature I look for in any debug GUI. It is extremely helpful to observe the data structure's memory as the code executes to get a full understanding of the system.
I hope this can be prioritized and implemented in a milestone soon
doingnz commentedon Aug 31, 2018
yes please add this is a standard feature
stuartthompson commentedon Jul 24, 2019
This would be a fantastic feature. This is the one reason I still run my code via gdb or lldb (depending upon which machine I'm working on) at the terminal instead of via vscode. Running exec x/ commands in the VSCode terminal just isn't an equivalent.
[-]Memory browser in debug view[/-][+][Feature Request] Memory viewer when debugging[/+]hyt589 commentedon Mar 25, 2020
Any updates on this feature?
sean-mcmanus commentedon Mar 26, 2020
Yutong Huang (@hyt589) We don't currently have any plans to implement this.
If your host machine is Windows, you could use Visual Studio's memory/registers viewer when debugging on Windows or remote Linux targets: https://docs.microsoft.com/en-us/cpp/linux/deploy-run-and-debug-your-linux-project?view=vs-2019.
andicam76 commentedon Jun 10, 2020
Please add this to the roadmap! That's a standard feature to debug in embedded systems with gdb. When developing my projects with VSCode, I still need to run eclipse in parallel for debugging because of this missing feature.
Trass3r commentedon Jul 21, 2020
For reference, here's the DAP spec change: microsoft/debug-adapter-protocol#50
WIP implementation: microsoft/MIEngine#816 (comment)
HuskyNator commentedon Aug 12, 2020
I might as well not use vscode and use visual studio instead . . . pretty disappointing.
I heard similar views when searching for a way of profiling, with many referring to visual studio 😕
WardenGnaw commentedon Aug 12, 2020
We are investigating ways to add a memory view to this extension using the VS Code Hex Editor
Danvil commentedon Dec 28, 2020
Ran into the same problem. For others who are stuck here: I am using a program called "Cheat Engine" in the meantime to look at disassembly and memory. It can connect to a running process and has a nice memory and disassembly. I copy the memory addresses from my VS Code debugging session over and can look at the memory (Ctr+G to jump to address).
4 remaining items
danderson-presonus commentedon Sep 28, 2021
upvote
bobbrow commentedon Sep 28, 2021
Upvotes are tracked using the 👍 in the first comment. Make sure you click on the 👍.
teaczjf commentedon Oct 26, 2021
4 year~~
Trass3r commentedon Oct 26, 2021
They focus on the disassembly view at the moment.
oltdaniel commentedon Oct 30, 2021
Hey everyone,
I started development on the MemoryView on my own, as I would really love to see this feature in vscode. https://github.com/oltdaniel/vscode-cpptools/tree/feature/memoryView
However, I'm currently stuck at getting information about the different Debug Session events like "pause". As this is my first every development with VSCode and its extensions, I don't have a perfect overview of everything. But the basic visualization is done and reading the memory is already supported by the underlying Debug Adapter Protocol.
There are some more or less active branches like https://github.com/microsoft/vscode/tree/connor4312/debug-read-memory at the main Editor Repo or https://github.com/microsoft/vscode-cpptools/tree/dev/waan/addMemoryView in this repo.
As this feature is required for a project of my own, I would love to contribute to this feature. Maybe Connor Peet (@connor4312) or Andrew Wang (@WardenGnaw) can tell us more.
connor4312 commentedon Oct 30, 2021
Yes, we are actively working on supporting DAP
readMemoryandwriteMemoryin VS Code core. This was put on pause last month for our housekeeping iteration, but will resume next week. Active development is mostly happening in the hex editor to support arbitrarily large files via a streaming model, which will be used support for program memory.readMemoryis likely land in the November iteration.This work can be tracked in microsoft/vscode#126268
WardenGnaw commentedon Nov 1, 2021
Closing this issue in favor for implementation in core VS Code.
The debug adapter already supports
readMemoryas it is used in the disassembly window.See microsoft/vscode#126268
epiciskandar commentedon Apr 1, 2022
Why this has been closed? the disassembly window is not the same as a Memory View window. And the hex editor can only open files, not the debugging memory with specific address.
So, MIEngine finished their works but still not done in VSCode, please keep tracking this feature request.
teaczjf commentedon Apr 1, 2022
mistakenforzen commentedon Apr 13, 2022
It is there, but has been implemented in an annoying and arbitrarily limited way. You are expected to hover over a variable in the locals section of the debugger side bar and click the hex icon. This opens up the hex editor to view the memory at the address pointed to by the local variable.
There is still no way to view any memory address. If you want to view any memory, you have to have a local pointer variable to it. You can't even view memory at addresses in registers.
NateAGeek commentedon Jul 3, 2022
I've created an extension that right now allows you to view a decent buffer of memory hex at an entered address: https://marketplace.visualstudio.com/items?itemName=NateAGeek.memory-viewer
Still very much a work in progress but feel free to tell me if it works well for cpp 🤙
teaczjf commentedon Jul 3, 2022
connor4312 commentedon Jul 3, 2022
Fyi this shipped in VS Code in January of this year https://code.visualstudio.com/updates/v1_64#_viewing-and-editing-binary-data
C++ supports this, via the "memory" icon when hovering on a variable
NateAGeek commentedon Jul 3, 2022
Connor Peet (@connor4312) My extension uses the "readMemory" and "writeMemory" DAP messages. So, it should work with any language implementation that supports those DAP messages.