Skip to content
Haneef Mohammed edited this page Nov 8, 2022 · 12 revisions

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