Uh oh!
There was an error while loading. Please reload this page.
Change VMPTR IPC events to ensure endianness consistency - #128058
Conversation
Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag |
There was a problem hiding this comment.
Pull request overview
This PR adjusts how VMPTR values are represented across the debugger IPC boundary to preserve endianness correctness: VMPTR becomes a host-endian wrapper over CORDB_ADDRESS, and IPC payloads should carry Portable<VMPTR> so they remain little-endian “on the wire” while converting back to host endianness on access.
Changes:
- Adds convenience forwarders on
Portable<T>to call pointer-like helpers (intended forPortable<VMPTR_*>) through the endian-converting operators. - Changes
VMPTR_Basestorage fromPortable<CORDB_ADDRESS>toCORDB_ADDRESS, and updates many IPC event fields fromVMPTR_*toPortable<VMPTR_*>. - Updates a couple of event-producing sites to initialize null
VMPTRvalues viaNullPtr()assignment.
Show a summary per file
| File | Description |
|---|---|
| src/coreclr/inc/dbgportable.h | Adds Portable<T> method forwarders intended to enable ergonomic use of Portable<VMPTR_*> fields. |
| src/coreclr/debug/inc/dbgipcevents.h | Moves endianness handling for VMPTR from inside VMPTR_Base to the IPC layer by wrapping many IPC fields in Portable<>, and adjusts some pointer field representations. |
| src/coreclr/debug/ee/debugger.cpp | Updates null initialization for vmAssembly in DebuggerIPCE_BasicTypeData to align with the new Portable<VMPTR_*> field type. |
Copilot's findings
- Files reviewed: 3/3 changed files
- Comments generated: 3
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
…ctExpandedTypeInfo (#128001) After #128058 goes in the `memcpy` from a VMPTR will be awkward but correct. I figured it's ok that it's awkward because this is not really something we should be doing all the time. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Rachel Jarvi <rachel.jarvi@gmail.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
rcj1
commented
May 22, 2026
/ba-g #128372 |
The inadvertent consequence of #127943 is that since VMPTR now wraps a
Portable<CORDB_ADDRESS>, VMPTR is propagated as a little-endian value across DBI, DAC, and EE, as opposed to solely in the IPC layer. Changing this such that VMPTR wraps CORDB_ADDRESS and we havePortable<VMPTR>in the IPC layer - remains little-endian in IPC, but the conversion operator to a VMPTR converts it to the machine endianness.