Problem
CDT GDB Adapter does not handle memory-changed notifications yet.
See bottom of https://sourceware.org/gdb/current/onlinedocs/gdb.html/GDB_002fMI-Async-Records.html
This leads to warnings that the support is missing.
Reproducer
Can be reproduced in my case with gdbtarget type, an embedded target that has valid memory or memory mapped peripherals at a certain address, and CLI commands like this (just change the address as needed):
> set {unsigned int}0xE0000E40 = 0x0000000F
GDB unhandled notify: memory-changed: {"thread-group":"i1","addr":"0xe0000e40","len":"0x4"}
This can become noisy when sourcing GDB scripts that for example configure some peripherals in the target system.
Proposal
Proposed solution is to handle those notifications and map them to Memory events of the DAP protocol: https://microsoft.github.io/debug-adapter-protocol/specification#Events_Memory . Exact mapping strategy needs to be figured out while working on this. (addr and len should be straight forward, don't know without further investigation what to do with thread-group...if anything is needed at all.)
Testing
If I interpret this code and this code correctly, then the Memory Inspector would listen for such events and refresh when affected memory is displayed. This could be used for more thorough testing.
I don't know if VS Code/Theia would refresh any built-in views on Memory events.
The most basic way of testing is to inspect the verbose GDB adapter output on the Debug Console.
We have a strong interest in getting this resolved, hence are happy to pick up ourselves.
If however someone else has a strong interested in picking this up (I expect it to be a good starter issue), then please comment here so that we don't duplicate efforts.
Problem
CDT GDB Adapter does not handle
memory-changednotifications yet.See bottom of https://sourceware.org/gdb/current/onlinedocs/gdb.html/GDB_002fMI-Async-Records.html
This leads to warnings that the support is missing.
Reproducer
Can be reproduced in my case with
gdbtargettype, an embedded target that has valid memory or memory mapped peripherals at a certain address, and CLI commands like this (just change the address as needed):This can become noisy when sourcing GDB scripts that for example configure some peripherals in the target system.
Proposal
Proposed solution is to handle those notifications and map them to
Memoryevents of the DAP protocol: https://microsoft.github.io/debug-adapter-protocol/specification#Events_Memory . Exact mapping strategy needs to be figured out while working on this. (addrandlenshould be straight forward, don't know without further investigation what to do withthread-group...if anything is needed at all.)Testing
If I interpret this code and this code correctly, then the Memory Inspector would listen for such events and refresh when affected memory is displayed. This could be used for more thorough testing.
I don't know if VS Code/Theia would refresh any built-in views on
Memoryevents.The most basic way of testing is to inspect the verbose GDB adapter output on the Debug Console.
We have a strong interest in getting this resolved, hence are happy to pick up ourselves.
If however someone else has a strong interested in picking this up (I expect it to be a good starter issue), then please comment here so that we don't duplicate efforts.