SOS: activate data access through dbgshim using cDAC support policy - #5966
Draft
hoyosjs wants to merge 4 commits into
Draft
SOS: activate data access through dbgshim using cDAC support policy#5966hoyosjs wants to merge 4 commits into
hoyosjs wants to merge 4 commits into
Conversation
SOS enumerates the runtime and hands the module base to dbgshim, which prefers the co-located cDAC and falls back to the legacy DAC. The resulting IXCLRDataProcess is registered with ClrMD (managed host, via DataTarget.AddLoadedRuntime) or returned to native SOS, replacing the direct cDAC LoadLibrary path. Remove the runtime-version gate from the cDAC load policy: every runtime attempts the cDAC and the cDAC's own contract-support validation decides. Rework Runtime.CreateRuntime so a cDAC that loads but declines falls back to the in-box DAC; a forced cDAC (UseCDac) stays a hard failure rather than silently using the DAC. Extract TryCreateRuntimeFromLibrary. Move the dbgshim managed interop (ICLRDebugging, ICLRDebuggingPolicy) from the test project into SOS.Hosting as the single product copy. Add IClrDataProcessActivator (DebugServices) implemented by ClrDataProcessActivator (SOS.Hosting), which loads the co-located dbgshim, sets the prefer-cDAC policy, builds a runtime-bound DataTargetWrapper, and returns the IXCLRDataProcess from OpenVirtualProcess.
Add greppable 'data-access:' trace lines at every branch of the cDAC/DAC decision in both the managed ClrMD path (Runtime.CreateRuntime) and the native SOS path (RuntimeWrapper.GetClrDataProcess): seam tried, seam activated the cDAC, seam declined, no seam in host, direct cDAC tried/declined, forced-cDAC hard failure, and in-box DAC fallback. A log now shows exactly which engine served each runtime.
Remove the remaining native runtime-version check and let the cDAC validate whether it can service each target. Carry the effective cDAC policy through the hosted dbgshim activator, including a cDAC-only mode that cannot silently fall back to the DAC. Preserve forced-cDAC rejection across the RuntimeWrapper boundary so native SOS and CLRMA do not replace it with DbgEng's DAC. Serialize per-activation dbgshim policy changes and keep the default prefer-cDAC fallback behavior for unsupported targets.
Make the IXCLRDataProcess service contract implementation-neutral and remove comments that describe callers, fallback policy, or historical behavior. Remove the direct ClrMD cDAC load and the separate cDAC path resolver from Runtime. cDAC activation now only occurs through the registered service; ClrMD loads only the DAC fallback.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Route SOS data-access activation through the co-located dbgshim and let the cDAC
decide whether it supports each target by validating its contracts, instead of
pre-filtering targets by runtime version.
IClrDataProcessActivatorservice implemented by SOS.Hosting.It creates a runtime-bound data target, loads the co-located dbgshim, applies the
requested cDAC policy, and requests
IXCLRDataProcessthroughICLRDebugging::OpenVirtualProcess.DataTarget.AddLoadedRuntime, so ClrMD builds its normal runtime services withoutloading another DAC.
.NET 11+version gates. Under the default policy,every eligible CoreCLR target tries the cDAC; unsupported targets fall back to the
matching DAC.
IRuntime::GetClrDataProcessflagsABI. Forced cDAC rejection is preserved through native SOS and CLRMA instead of
being replaced by DbgEng's DAC.
ICLRDebugging/ICLRDebuggingPolicyinterop definitions fromthe test project into SOS.Hosting as the product implementation.
data-access:messages.Behavior
CDAC_E_DESCRIPTOR_MALFORMED; matching DAC is loadeddbgshim policy is set for each activation while holding the activator lock, so
concurrent requests cannot race different policy values on the shared
ICLRDebugginginstance.Verification
Built from:
6bbbb2ce68069b76e6710.0.1111.0.0-rc.1.26413.10310.0.26100.1Product builds
SOS.Hosting.csproj: 0 warnings, 0 errorsdotnet-dump.csproj: 0 warnings, 0 errorstools.cdac: 0 warnings, 0 errorsEnd-to-end
Ran
runtimes,clrstack, anddumpheap -statagainst fresh full dumps:Program.Main; 246 objectsProgram.Main; 346 objectsProgram.Main; 246 objectsProgram.Main; 346 objectsForced-cDAC cases were also verified under both hosts:
0x80131C46at the SOS boundary).CDacOnly.Tests
DbgShim.UnitTestswithPrivateBuildTesting=true: 36 passed, 0 failed.Known test-environment issues
Debuggees.projprocess exits with-2147450725. The affected product projectsand native build succeed independently.
are single-file configurations returning
CORDBG_E_LIBRARY_PROVIDER_ERROR (0x80131C43)after the debuggee-asset buildfailure above. The supported private matrix passes.
cdb-sospackage does not contain the defaultntsdexts,uext, orextsextension DLLs. CDB warns while loading them, but the explicitly loadedSOS and every command used for this verification succeed.