microsoft / microsoft/debug-adapter-protocol
Add a `memoryType: assembly` to `Variable`
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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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