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)
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
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, custom
MemoryType
. 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)