microsoft / microsoft/debug-adapter-protocol

Add a `memoryType: assembly` to `Variable`

Open
#495 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
HTML
Stars
1.8k
Forks
173
Avg merge
7d 7h
Merged PRs (30d)
2

Description

Use case

For pointers, the memoryReference attached to a pointer points to the corresponding memory.
Currently, this memory is shown in VS-Code in the hex-editor.

However, for function pointers, it would be more ergonomic to show this memory area in the disassembly view.

Proposal

type MemoryType = 'raw' | 'assembly';

interface Variable {
  // ...
  
  /**
   * A memory reference associated with this variable.
   * For pointer type variables, this is generally a reference to the memory
   * address contained in the pointer.
   * For executable data, this reference may later be used in a `disassemble`
   * request.
   * This attribute may be returned by a debug adapter if corresponding
   * capability `supportsMemoryReferences` is true.
   */
  memoryReference?: string;
  /**
   * Determines the type of memory which this memory reference is
   * referring to.
   */
  memoryType?: MemoryType;
}

// Similar for `EvaluateResponse`, `Output`, `SetExpressionResponse`

The UI could then open either the disassembly or the hex-editor for the given memoryReference, as appropriate. (Or even offer a choice to the user whether to use the disassembly or the hex-editor view).

This might also be useful in combination with microsoft/vscode#197287, where extensions might introduce own, customMemoryType. E.g., I could imagine other extensions to contribute a PNG-viewer which allows viewing PNGs directly from within the program's memory. (But I don't have any particular use case in that direction. My main motivation here is to get better default-behavior for function pointers)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the MemoryType and Variable definitions in the protocol, then review the related EvaluateResponse, Output, and SetExpressionResponse definitions named in the proposal. Trace how memoryReference is documented and represented across these entry points; done means the assembly memory type is specified consistently for all proposed response types and the existing memory-reference behavior remains clear.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
api, devtools
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.