You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
typeMemoryType='raw'|'assembly';interfaceVariable{// .../** * 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)
The text was updated successfully, but these errors were encountered:
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)The text was updated successfully, but these errors were encountered: