Don't expose a memory reference for non-pointer evaluation results#1601
Conversation
|
Hi @tieo thank you for taking the time to investigate this. I didn't debug this, so apologies if I am incorrect, but, at least in Visual Studio, I believe your change would break entering an address into the memory or disassembly window. I haven't looked at how the memory or disassembly windows work in VS Code to know if they let the user enter an expression for the memory address to know if they have the same problem or not. Are you looking specifically to block the memory window just from data tips? |
A non-pointer scalar shown in a data tip or the Variables view carried a memoryReference, so VS Code rendered the "view binary data" icon and navigated to an address equal to the value (hovering a uint32_t of 1 opened a memory view at 0x1). The earlier approach gated AD7Property.GetMemoryContext in the engine, but that method is shared with Visual Studio, where the Memory and Disassembly windows resolve a typed address expression through it. Restricting it there breaks entering a scalar or address expression into those windows. Move the restriction to the DAP layer: in AD7Utils.GetMemoryReferenceFromIDebugProperty, emit a memoryReference only when the property type is a pointer or an array. GetMemoryContext is left unchanged, so the Visual Studio memory and disassembly navigation keep working, while VS Code no longer offers a memory view for scalars. VS Code has no free-form address entry, so gating the reference removes no entry point there.
a3a8a4f to
033b659
Compare
|
It looks like, at least for now, VS Code's disassembly window and memory window don't offer an "address bar" where one could type in a different address, so I think your fix is workable in VS Code. To do so, you will need to add a check like: |
I am sorry, you are in OpenAD7 already, So you are good there. |
Problem
In a debug data-tip (or the Variables view), hovering a non-pointer scalar shows the value correctly but attaches a
memoryReference, so VS Code renders the "view binary data" hex icon and clicking it navigates to an address equal to the value. For example, hovering auint32_t stsdigwhose value is1offers a memory view that opens at address0x1.Cause
AD7Property.GetMemoryContext(src/MIDebugEngine/AD7.Impl/AD7Property.cs) tries to interpret the result's display value as a memory address, for every type:For a pointer this is correct — the value is an address (
0x...). For a plain scalar (e.g.int/uint32_t) the value is a number, not an address, soUInt64.TryParse("1")succeeds and the memory reference becomes0x1. OpenDebugAD7 then reports that asmemoryReferenceon theevaluate/variablesresponse, and VS Code's memory navigation goes to address1.Fix
Only treat the value as an address when the result is a pointer (or an array, which already re-evaluates to its address with
&(...)further down). For any other type, returnS_GETMEMORYCONTEXT_NO_MEMORY_CONTEXTso nomemoryReferenceis reported and no spurious memory icon/navigation appears.TypeNameis already onIVariableInformation, and the sameEndsWith("*")pointer test is used elsewhere inVariables.cs(IsPointer).Testing
Built the patched engine and ran it against a live
cppdbg/gdb session:int32_t *,const uint32_t *) — still shows its address and the memory icon, unchanged.uint32_t) — now shows just the value, with no memory icon and no navigation to0x<value>.&(...)path).Note: the change was written with the help of an LLM and verified manually in VS Code against a real gdb target.