Provide a way for DA's to control page size of readMemory

[connor4312]

Feedback from microsoft/vscode#155597 (comment)

Currently DAP does not specify a page size for readMemory, nor provide a way for DA's to request one. VS Code requests 128KB simply because we can quickly and easily display that amount of data in the editor, but it sounds like that may be too big for some devices.

I think the right place for this is in some initialize-type request. It's not a "capability"--should we add a new parameter to the direct return arguments of initialize, such as memoryPreferredPageSize?: uint?

[roblourens]

Not knowing much about this, is this a property of the debug adapter, or more the device/runtime/something else (which the DA wouldn't yet know about in initialize)?

We could also just have a better way for DAs to return fewer bytes than requested from readMemory.

[haneefdm]

I contend that the HexEditor should never need to read 128KB at all. This is not good client behavior, IMO. For memory views, the page size should be very small, regardless of where the program is running. Easily fixed in the Hex Editor (I found the line of code where this is done).

I think 128KB is okay for actual file systems even networked ones. Could be smaller but, l would leave it alone.

Let us say, we did a memoryPreferredPageSize that the DA can tell you. How would a DA like cppdbg/cortex-debug/MIEngine know what that would be? We have not started a debug session yet, we don't know what kind of a target we have (a tiny microcontroller or desktop/server CPU, a real OS, remote connection with unknown speed). Most micro-controllers, IOT devices top out at 1Mbit transfer speed.

When initialize is called, we haven't started a debugger or a debug-server (gdb-server) yet. All that does not happen until a launch/attach request comes in. Sure, you can do a capabilities update...

My opinion, clients should not ask for too much data at a time. There is really no tangible benefit to that as this is not a streaming interface. Things get bottled up throughout the software stack. VSCode->HexEdit->cppdbg->gdb-server .... At each stage, entire memory blob has to be collected and pushed through.

If such a memoryPreferredPageSize is needed, then cortex-debug will probably just say 4KB blindly :-)

If we make a large request to GDB, then it will stall until it reads/returns the whole thing and you cannot step/continue for a while. GDB does sometimes break up large reads but does not return until the full packet is assembled.

[noppej]

I would like to +1 this request from @haneefdm. probe-rs has implemented a RUST based DAP debugger and VSCode extension for embedded devices. Attempting to read 128K of data from an embedded device through a USB based probe, results in an unusable user experience (it can take minutes to complete).

See probe-rs/probe-rs#1275 for tracking of this issue on our side.

[connor4312]

Thanks for the feedback, I put in a PR to the hex editor to change the page size used for debug memory to 4KB: microsoft/vscode-hexeditor#390

[noppej]

Thanks for the feedback, I put in a PR to the hex editor to change the page size used for debug memory to 4KB: microsoft/vscode-hexeditor#390

Thank you @connor4312 !!

[noppej]

@connor4312 ... Do you have a schedule / ETA for when this fix will be released?

[connor4312]

I'm planning a hex editor release next week

[noppej]

@connor4312 ... just pinging for an updated ETA if you have one please :)