Support for a new WriteMemoryRequest if debuggee permits to

[yannickowow]

Hi,
In order to implement a full set of debug tools from DAP, I would like if it would be ok to implement a request such as WriteMemoryRequest, the same way it works for ReadMemoryRequest

interface WriteMemoryArguments {
  /**
   * Memory reference to the base location from which data should be written.
   */
  memoryReference: string;

  /**
   * Bytes to write, [encoded using base64 like ReadMemoryRequest ?]
   */
  content: string;

  /**
   * Optional offset (in bytes) to be applied to the reference location before
   * writing data. Can be negative.
   */
  offset?: number;
}

For the response, I don't know if it can be the same way as ReadMemoryResponse. It can also be a new Memory event with a flag 'modified' and a content/address

interface WriteMemoryResponse {
  // body is not mandatory if write has worked correctly
  body?: {
    /**
     * The address of the first byte of data returned.
     * Treated as a hex value if prefixed with '0x', or as a decimal value
     * otherwise. (It would match previous memoryReference+offset)
     */
    address?: string;

    /**
     * The bytes read from memory, encoded using base64.
     */
    data?: string;
  };
}

Thanks in advance

[connor4312]

The "write" request makes sense. I'm not sure about the response--is the use case to return that if the write only partially succeeded?

---

We also should have readMemory return information about whether the memory is writable, and whether it can be resized. In languages where the binary data is in a well-defined container, like JS or Python, we can grow or shrink it by assigning a new value. However, in statically compiled languages, changing the size of data is likely to be illegal.

[yannickowow]

Exactly. My first proposition was to ensure that content has been updated correctly.
If data is empty, we should consider that data has been correctly written. Else, we use returned data to update current view based on returned address.

For your second point, I was considering C/C++ debugging in a view which should not grow nor shrink memory size, but rather edit it in place.

[connor4312]

I'm not very familiar with C/++ debugging. Are there cases where a write to memory would fail? From the little C work I've done, wouldn't it either always succeed or (if the write was in an unallocated/freed area) segfault?

[gregg-miskelly]

On some devices/operating systems it could partially succeed if the address range crossed a memory page boundary such that some of the addresses were valid and writable while others were not.

If we want to support partial failures, I wonder if we should have this return a 'bytesWritten' count instead of returning data.

[yannickowow]

Good point, bytesWritten looks more adequate and lighter than a whole data content

[weinand]

Thanks for the proposal and the subsequent discussion.

Yes, I prefer the bytesWritten count over returning the written data.

@gregg-miskelly you said:

[ a WriteMemoryRequest ] could partially succeed if the address range crossed a memory page boundary such that some of the addresses were valid and writable while others were not

This means that a WriteMemoryRequest with a large address range could cross more than one page each with different write permissions. Do we need a way to return multiple address and bytesWritten properties? And would a client actually want to show this in the UI?

Or is it enough to have a single address and bytesWritten property, and bytesWritten would have the total number of bytes written?