Add new Memory Event to refresh an address range

[yannickowow]

Hi,
I open this request to have the ability to throw an event if a range of address has been updated.
Here is my first idea:

• An event will inform a starting address that has been updated
• This event will contain the new data
• If this content is longer and filled by zeroes, an optional count can be used.

Thanks

interface MemoryEvent extends Event {
  event: 'memory';

  body: {
    /* Start address where memory has been updated */
    address: string;

    /**
     * The bytes read from memory, encoded using base64.
     */
    data: string;
    /* Number of bytes updated
     * If not specified, calculated using data length. 
     * If specified, fulfill with zeroes until count matches
     */
    count?: number;

  };
}

[connor4312]

The invalidated event is what we use in other areas for this, which will trigger the UI to refresh data as needed. Would that work for this use case?

I think we would also implicitly invalidate memory if the source of the memory being read (e.g. variables) changed

[yannickowow]

Hi,
It should work I guess. However, how to be sure that, using a Memory Viewer for example, we highlight the correct value in a given context ? Without infos about addresses, we only can do a diff between old and new memory content ?

EDIT: I was using GDB "Memory Changed" event as a reference:
=memory-changed,thread-group=id,addr=addr,len=len[,type="code"]

A memory changed for a given range should trigger a refresh. It should be perfect if we can Invalidate a given address and length

[weinand]

@yannickowow thanks for the proposal

Introducing a new event with specific properties for Memory ranges makes sense and corresponds to the other DAP events for Modules, Threads, LoadedSource, and Process.

I do not recommend to use the Invalidated event for this, because that event should be used to signal that some state in the debug adapter has changed (as opposed to state in the debuggee). An example for a debug adapter state change is a change of the format of variables.

@gregg-miskelly @yannickowow @connor4312
If there are no objections, I'll proceed updating the DAP schema.

[yannickowow]

Another possibility is to send an event with address and count (which will be required) but without data. And, after this event, a GUI need to send a readMemoryRequest with these attributes.
Since we tried to remove data from writeMemoryRequest do we need to remove data here as well for consistency ?

[gregg-miskelly]

I am assuming the primary scenario here something like: the client has a memory window, and the something decides make an operation that writes to memory (for example, the user modifies a local variable) and we want to let the memory window know that it should refresh the given address range if it was being shown. Is that correct?

Assuming so:

I think I would agree with @yannick-mamudo that we probably want to remove data since conceivably there could be a lot of these, and the client probably mostly doesn't care.

If a DA knows that some memory changed, but doesn't know what memory that was (ex: an assignment where the underlying debugger doesn't easily expose what addresses were modified), should we use an Invalidated event? Or should we allow address to be optional?

[puremourning]

I don’t think clients have any way to ‘interpret’ memoryReferences. They are opaque to clients so even if server returned an address and count, client would not have any way to map that to something it knows about.

Agree that Invalidated seems wrong for this, but in either case it requires the DA to remember (somehow?) that client has a memory window open for a given range. Unless I’m missing something, without this wouldn’t this event be really noisy… like every write to memory triggering an event?

if the intention is to only raise these events when the client cares, then there needs to be some synchronisation for client to request and then cancel these updates? Am I missing something obvious?

[yannickowow]

I don’t think clients have any way to ‘interpret’ memoryReferences. They are opaque to clients so even if server returned an address and count, client would not have any way to map that to something it knows about.

Yes you're right. But this event should return an address, and client interprets this as decimal or hexadecimal if it starts by 0x or not. Using memoryReferences on a request, it "resolves" to an address on response. (If I understand correctly)
See the ReadMemory description: https://microsoft.github.io/debug-adapter-protocol/specification#Requests_ReadMemory

Agree that Invalidated seems wrong for this, but in either case it requires the DA to remember (somehow?) that client has a memory window open for a given range. Unless I’m missing something, without this wouldn’t this event be really noisy… like every write to memory triggering an event?

If a client does not have a Memory Window opened, event will be ignored. Else, event should be raised by a Debug Adapter on memory update. This behaviour has nothing to do w/ client and should be handled with care from a DA.

That's why I suppose that we need to remove data from my previous feature request, because if window is closed, this event can be quite heavy. In the second hand, you might not call for a readMemoryRequest.

[puremourning]

a client does not have a Memory Window opened, event will be ignored
should be handled with care from a DA
In the second hand, you might not call for a readMemoryRequest.

I still think there's a pathological case here. if the server is to produce an event on any change to any memory that ever had a readMemeoryRequest made for it, then on a long debug session, can't that combine to a lot of redundant chatter.

Example:

• start a debug session
• open memory window and readMemory (range A - B)
• close "memory window" in client
• open memory window and readMemory (range C - D)
• close "memory window" in client
• ... etc.
• open memory window and readMemory (range Y - Z)
• close "memory window" in client
• At this point, is the debug adapter sending updates for all writes to memory in range A-Z, even though the client does not have any memory window open?

I agree that removing data reduces the chatter somewhat, but it's still potentially significant work for both client and adapter.

Using memoryReferences on a request, it "resolves" to an address on response

I didn't realise that was the intention of the address result in ReadMemoryResponse, but I guess it's workable.