Memory Viewer

Memory Viewer/Editor Design

These are my current thoughts. A lot of my thinking comes from what embedded IDE's do for memory views. Even non-embedded IDEs such as Visual Studio do a good job at this. What we have in VSCode today is lacking in many ways, some of which easily corrected

• Not very efficient. Asking for 128KB is a bit much and it interferes with user experience for fast single stepping.

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
  • Two choices
  • Multi-Window per memory view~~
  • 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
    • Two 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.
    • 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