Add universal DBI with private PAL

[hoyosjs]

Adds mscordbi_universal, a DBI that owns its own PAL instead of borrowing the DAC's, and bundles it in Microsoft.DotNet.Cdac.Transport. It's built for the cDAC ICorDebug path and is not tied to the brittle shared-DAC-PAL coupling of legacy mscordbi, which is left unchanged.

It exports only the two entrypoints the bundled dbgshim uses: OpenVirtualProcessImpl2 (path-based activation) and CoreCLRCreateCordbObject3 (in-proc creation). DllMain is not exported, so each entrypoint brings up the private PAL on first use.

[azure-pipelines]

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.

[Copilot]

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_universal native build (CMake + export definition files) under src/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 OpenVirtualProcessImpl2 rather than HMODULE-based activation flows).
• Include the new mscordbi_universal binary in the Microsoft.DotNet.Cdac.Transport package.

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.

[Copilot]

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

[Copilot]

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 exports CoreCLRCreateCordbObject3 (even if marked private, 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 uses WszGetModuleFileName(hInstance, ...) under LOGGING, so passing a null module handle can cause misleading diagnostics (it may resolve to the host/exe rather than mscordbi_universal). Since the universal DBI hosts its own PAL, you can pass a proper PAL HMODULE via PAL_GetPalHostModule() here.

static void UniversalDbiInitOnce()
{
    s_universalDbiInitSucceeded = DbgDllMain(NULL, DLL_PROCESS_ATTACH, NULL);
}

[noahfalk]

👍