Allow editing the memory values

[hegdemurali]

I like this extension, as this allows me to examine the memory contents during debugging my application. Currently i am only able to read the memory contents when debugger is stopped but cannot edit/write to it.

Describe the solution you'd like

It would be really nice, if we will also be able to edit/write to the memory and read back if the values are written actually to the target hardware. This would be quite useful where we often use peripheral address spaces (E.g.. Timer, GPIO etc.). I can easily examine the behavior of the module by configuring the peripheral.

Another use case would be to instrument variables in initialized RAM area and see how this will affect the behavior of the application.

Describe alternatives you've considered

I can use GDB memory write command of course, but with memory view the we can have more rich experience.

[Lee20171010]

For the write memory feature, since this extension relies on the Debug Adapter Protocol (DAP), the ability to directly use the 'writeMemory' command depends on the debugger's supportsWriteMemoryRequest capability.

For debuggers like GDB, this capability currently returns false, which prevents the direct use of the DAP's standard write memory command.

Fortunately, GDB does support both the supportsSetExpression and supportsSetVariable capabilities (returning true). I've leveraged these to create a workaround for writing memory values:

For setting memory: I'm using the setExpression and setVariable commands to achieve the desired effect of modifying memory contents.

While this approach successfully enables memory editing, it's a non-standard implementation and not a direct use of the DAP's intended 'writeMemory' command. For this reason, I'm currently keeping this implementation local.

I would appreciate thoughts on whether this workaround is an acceptable temporary solution until more debuggers natively support supportsWriteMemoryRequest, or if we should prioritize finding a way to integrate this non-standard but functional method into the main branch.

[haneefdm]

For debuggers like GDB, this capability currently returns false

Which debugger is that? This one?

https://github.com/WebFreak001/code-debug

More than 5 years ago, cortex-debug was based on that. I see that it has neither read or write memory support? I did a cursory look at the source code, so I could be wrong.

The reason I did not finish implementing writing to memory was because of user interface issues. I just could not get react to make edit in place look natural. Didn't have the time. Next thing you know, people want to paste values like excel sheets, select a range and clear. For the rare occasion you need to write to memory, writing via gdb commands.

There was another issue. After writing, there is no guarantee that gdb will actually write to the device because of how elf section permissions are set. This already a problem with FLASH where if an area of FLASH was programmed by the FW, and then ask gdb to read that area, it will return the cached values because it thinks that area was not writable according to Elf attributes. I did not try the following gdb settings (not something I would do from memview as backend may not be gdb)

set code-cache on
set code-cache off
    Enable or disable caching of code segment accesses. When on, use caching. By default, this option is on. This improves performance of disassembly in remote debugging.

show code-cache
    Show the current state of target memory cache for code segment accesses.