-
Notifications
You must be signed in to change notification settings - Fork 237
Memory Viewer
Haneef Mohammed edited this page Nov 8, 2022
·
12 revisions
Since publishing this wiki, we have moved on. All of the ideas listed below have been implemented as a separate extension. You can see it here. https://github.com/mcu-debug/memview
But please read the rest below to see why we did it.
These are my current thoughts. A lot of my thinking comes from what embedded IDEs do for memory views. Even non-embedded IDEs such as Visual Studio do a good job at this. What we have in VSCode today has a few shortcomings, some of which are easily addressed but not sure if these ideas will be entertained.
- Not very efficient. Asking for 128KB is a bit much and it interferes with the user experience for fast single stepping. Some gdb-servers can't even comply. OpenOCD used to have an (8KB - 1) limit on memory reads. In cortex-debug we actually go out of our way to split up large requests into 4KB chunks for SVD view.
- It currently does not update when the program pauses...when this is implemented, item #1 above will become a big problem from performance and User experience.
- Lifecycle is not very user-friendly. Windows should be persistent -- even across a reload/restart of VSCode.
- Addresses are not reflected in the memory view -- they always start from
0x00000000
. I have to use a calculator to figure out which is where. I believe I had already fixed this but is not being used.
It is preferable that vscode/hex-editor meets the goals or lets us help in achieving that, but I am not sure we will get an agreement on the goals.
- We create a new extension or provide an API from the existing cortex-debug extension. We want to be a client of a debug session. We are not the primary debug adapter client which provides debug configurations, aids in launch/attach, etc. We are independent, secondary clients that work on active debug sessions and provide a service. How this service becomes available is TBD
- Each debug session shall have zero or more persistent memory views
- Lifecycle: A memory view shall have the following states
-
connected
- currently connected to a session
- updates memory whenever the debugger pauses
- can have a live mode if the debugger supports it. User HAS to enable this
- can be writable if the debugger supports the
writeMemory
request. - can save to a file and be opened with the hex-editor
- Need to figure out how the debugger communicates its capabilities
- Perhaps debuggers register with the memory viewer
-
orphaned
- not connected but have an associated session name
- still visible (neither us or the user has deleted the view)
- no writes are possible
- can save to a file and be opened with the hex-editor
- can be adopted by a new session with the same name as before and transition to a
connected
state
-
dead
orzombie
- not connected and removed from VSCode and should not be reused. User didn't want this so there...
-
dispose
may not have been called yet - for some reason, removal seems to be lazy - Maybe we don't need this state at all
- When vscode closes, all
connected
andorphaned
windows are saved in some storage - like global storage for workspace. - When vscode opens, all views are restored in the
orphaned
state
-
- View and Windows
- Would like to have expressions for an address that is resolved by evaluating. The window/tab will be named using said expression and shall be editable (if UI allows)
- Two choices
-
Multi-Window
one window per memory view- In this case, the windows will all be in the editor area
-
Single-window
hosts all memory views. Kinda like the Terminal. This is my preferred method- Can be hosted in the OUTPUT panels alongside TERMINAL.
- Can be hoisted into the Editor area
- Three choices (no preference yet but will only do one style)
- TERMINAL style: The design will be four columns. Inspector | Addr+Data | Decoded-text | View-Selector
- Tabbed view: Each memory element is in a TAB and has the ability to add a new view by clicking on a '+' button.
- Drop down list of views, similar to 'OUTPUT' or 'DEBUG CONSOLE'. Saves key vertical real estate.
- Obvious flaw is you can only see one memory view at a time Probably 99% use case
-
- Efficiency is paramount.
- Request as little memory as possible -- just the viewport and a bit beyond in either direction
- Provide infinite scrolling until reads fail and handle failures gracefully
- Scrolling should be fast and lazy. As in do not fetch data until the user stops but indicate data as dirty
- No scrolling beyond the start address in the negative direction
- Making this a separate extension: Perhaps we can convince MS to use this or provide some way for users to configure with Uri scheme they want to use for memory views. Use the hex-editor (default) or this-yet-to-be-named one or something else. MS uses a Uri scheme called
"vscode-debug-memory"
to identify who can handle it. VSCode could have a debug setting to say which Uri scheme to use. Better yet, they adopt this proposal and run with that. - Future work
- Mapping memory to data structures and having a data structure view in place of an inspector view