Question about VM vs DevTools responsibility for Pointer inspection
Ibn Ahmad
When exposing dereferenced pointer data to DevTools, would we prefer the VM Service Protocol return already-structured field data (offset + typed value) or should it return raw memory bytes and just let DevTools handle the layout interpretation?
I’m trying to understand where you see the cleanest separation of responsibilities between VM and tooling..
Daco Harkes
--
You received this message because you are subscribed to the Google Groups "dart-gsoc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dart-gsoc+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dart-gsoc/950521b4-7c56-43fb-b523-b53fab9efe13n%40googlegroups.com.
Ibn Ahmad
My proposed approach:
VM Service Protocol: add a small RPC that safely reads memory bytes
Example shape: readMemory(address, length) -> { bytes } or { error }
This would give us a useful baseline even when we dont know the static Pointer type.
VM Service Protocol: add a separate RPC for FFI layout metadata for Struct/Union classes
Example shape: getFfiLayout(classId) -> fields with { name, offset, size, nativeType }, plus alignment/size
This reuses the VM’s existing FFI layout computation so tooling does not need to reimplement the rules.
DevTools: add a Pointer renderer in the Object Inspector
Always show address + a hex view (based on readMemory)
If a concrete struct type is known (either selected by the user in DevTools, or provided later via DAP), show a “Fields” panel that decodes values using { bytes + layout }.
If readMemory fails, show a non-fatal error like “Could not read memory at 0x…”.
Safety plan (VM runtime):
Implement a guarded read path that attempts the memory copy and converts access violations into an error result.
On Linux/macOS: temporary SIGSEGV/SIGBUS handler around the read (scoped), returning an error instead of crashing.
On Windows: catch access violations via SEH for the read path.
Add guardrails like max read siz and keep the handler strictly scoped to the debug read.
Pros/cons:
Bytes-only from VM: simplest VM/protocol, great fallback but DevTools needs layout to show fields.
Structured fields from VM: best UX but pushes decoding and type handling into the VM and protocol and I think it might be harder to evolve as well.
bytes + layout metadata method: keeps VM responsible for safe read + authoritative layout, keeps decoding/UI in DevTools and still supports a great “raw hex” fallback.
Next steps I’m planning on taking:
First I’ll prototype the DevTools Pointer view using mocked payloads (hex + fields) to validate the UI.
Then I’ll wire it to a real VM service call for bytes, followed by layout metadata.
In parallel I’ll scan the library-ffi issues marked “contributions welcome” and try to pick a small starter issue to land a PR.
Once I have the first UI prototype working I can share screenshots and a short writeup comparing the approaches with concrete tradeoffs.
Thank you so much
Best,
Ibn
Daco Harkes
To view this discussion visit https://groups.google.com/d/msgid/dart-gsoc/17cc2964-16fb-4e47-b4f6-d0b4c8681fe9n%40googlegroups.com.