Memory Viewer

New Memory View

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.

Memory Viewer/Editor Design

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.

Design notes

• 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 or zombie
    • 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 and orphaned 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