Add universal DBI with private PAL - #131458
Conversation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 4c34245d-758e-44f8-a284-9e2fb9a62d3d
|
Azure Pipelines: Successfully started running 4 pipeline(s). 12 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
There was a problem hiding this comment.
Pull request overview
This PR introduces a new CoreCLR native module, mscordbi_universal, built in parallel to mscordbi but linked with a private PAL, and wires it into the Microsoft.DotNet.Cdac.Transport packaging so it can ship alongside mscordaccore_universal.
Changes:
- Add a new
mscordbi_universalnative build (CMake + export definition files) undersrc/coreclr/dlls/, reusing the existing DBI entrypoint source but linking a private PAL on Unix. - Define a reduced export surface for the universal binary (focused on
OpenVirtualProcessImpl2rather than HMODULE-based activation flows). - Include the new
mscordbi_universalbinary in theMicrosoft.DotNet.Cdac.Transportpackage.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| src/installer/pkg/projects/Microsoft.DotNet.Cdac.Transport/Microsoft.DotNet.Cdac.Transport.pkgproj | Adds mscordbi_universal to the native binaries packaged with the transport. |
| src/coreclr/dlls/mscordbi_universal/mscordbi_universal.src | New Windows export definition for mscordbi_universal. |
| src/coreclr/dlls/mscordbi_universal/mscordbi_universal_unixexports.src | New Unix exports list for mscordbi_universal. |
| src/coreclr/dlls/mscordbi_universal/CMakeLists.txt | New CMake target building and installing mscordbi_universal, including private-PAL linking on Unix. |
| src/coreclr/dlls/CMakeLists.txt | Adds the new subdirectory so the target is built with the rest of CoreCLR dlls. |
| ; This binary owns its own PAL and only supports the path-based OpenVirtualProcessImpl2 | ||
| ; activation flow, so the HMODULE-taking OpenVirtualProcessImpl and the deprecated | ||
| ; OpenVirtualProcess/OpenVirtualProcess2 entrypoints exported by dlls/mscordbi/mscordbi.src | ||
| ; are intentionally omitted here. The remaining export set matches mscordbi.src; only the | ||
| ; LIBRARY name differs so the module's internal name matches mscordbi_universal.dll. |
Remove PAL_RegisterModule and PAL_UnregisterModule from mscordbi_universal's Unix export list. DllMain stays exported so the Unix PAL loader can discover it via dlsym; DbgDllMain calls PAL_InitializeDLL itself, so the private PAL still initializes. Module registration is optional in the loader, and the path-based ABI never hands a cross-PAL module handle to this binary, so the registration handshake is unused. Legacy mscordbi is unchanged. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 7fd85a9c-de79-4f49-894a-084d4ab85aef
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 7fd85a9c-de79-4f49-894a-084d4ab85aef
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
src/coreclr/dlls/mscordbi_universal/mscordbi_universal_unixexports.src:25
- On Unix PAL loads, if the module doesn't export PAL_RegisterModule, the loader falls back to using its own PAL's MODSTRUCT as the HINSTANCE passed to DllMain. Since mscordbi_universal links a private PAL, passing a foreign-PAL HINSTANCE into DbgDllMain can break any PAL APIs that interpret that handle (e.g., WszGetModuleFileName under LOGGING). Exporting PAL_RegisterModule/PAL_UnregisterModule (as mscordbi does) lets the loader obtain an HINSTANCE in this binary's PAL context while still avoiding any HMODULE-based public entrypoints.
; DllMain is exported for the Unix PAL loader to discover via dlsym; DbgDllMain calls
; PAL_InitializeDLL itself, so the private PAL still initializes. PAL_RegisterModule and
; PAL_UnregisterModule are intentionally not exported: the loader treats registration as
; optional, and the path-based ABI never hands a cross-PAL module handle to this binary.
DllMain
… set The universal DBI no longer exports DllMain. Each of its two exported entrypoints (CoreCLRCreateCordbObject3 and OpenVirtualProcessImpl2) brings up this binary's private PAL on first use through a run-once helper. A run-once guard is required rather than relying on PAL_InitializeDLL being idempotent because the DLL_PROCESS_ATTACH path also performs one-time debug transport setup that is not safe to repeat. The bundled cDAC-aware dbgshim only resolves those two entrypoints on this binary, so CoreCLRCreateCordbObject, CoreCLRCreateCordbObjectEx, DllGetClassObject and DllGetClassObjectInternal are no longer exported. Dropping the CreateCordbObject fallbacks is safe because dbgshim resolves CoreCLRCreateCordbObject3 first and this binary always exports it. Legacy mscordbi is unchanged. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 7fd85a9c-de79-4f49-894a-084d4ab85aef
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 8 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (2)
src/coreclr/dlls/mscordbi_universal/mscordbi_universal.src:17
- PR description says the universal binary exports only
OpenVirtualProcessImpl2, but this.def/export list also exportsCoreCLRCreateCordbObject3(even if markedprivate, it is still exported; it’s just omitted from the import library). Either update the PR description to match the actual export set, or drop this export if the intent is truly single-entrypoint.
EXPORTS
; In-proc creation path from the shim
CoreCLRCreateCordbObject3 private
; Out-of-proc creation path from the shim - ICLRDebugging
OpenVirtualProcessImpl2
src/coreclr/debug/di/cordb.cpp:80
- Universal DBI init currently calls
DbgDllMain(NULL, ...). On Unix,DbgDllMain's attach path usesWszGetModuleFileName(hInstance, ...)underLOGGING, so passing a null module handle can cause misleading diagnostics (it may resolve to the host/exe rather thanmscordbi_universal). Since the universal DBI hosts its own PAL, you can pass a proper PAL HMODULE viaPAL_GetPalHostModule()here.
static void UniversalDbiInitOnce()
{
s_universalDbiInitSucceeded = DbgDllMain(NULL, DLL_PROCESS_ATTACH, NULL);
}
Adds
mscordbi_universal, a DBI that owns its own PAL instead of borrowing the DAC's, and bundles it inMicrosoft.DotNet.Cdac.Transport. It's built for the cDAC ICorDebug path and is not tied to the brittle shared-DAC-PAL coupling of legacymscordbi, which is left unchanged.It exports only the two entrypoints the bundled dbgshim uses:
OpenVirtualProcessImpl2(path-based activation) andCoreCLRCreateCordbObject3(in-proc creation).DllMainis not exported, so each entrypoint brings up the private PAL on first use.