Forward ICLRSymbolProvider calls to a host-supplied symbol resolver#5877
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR plumbs ClrMD’s symbol-resolution hook through the diagnostics host so both ClrMD’s data target and SOS’s legacy-DAC COM data target can resolve module-qualified symbols via a host-provided implementation. It also adjusts extension loading to proactively run module initializers and refactors some runtime-type/DAC selection logic.
Changes:
- Add a per-target
IClrSymbolProvideradapter over the host’s module/symbol services and pass it into ClrMD viaDataTargetOptions.SymbolProvider. - Expose
ICLRSymbolProvideron SOS’s legacy-DAC data-target CCW and forward calls to the sharedIClrSymbolProviderservice. - Run extension module initializers at load time; refactor runtime flavor→type mapping and add a CDAC fallback in
GetDacFilePath.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| src/SOS/SOS.Hosting/DataTargetWrapper.cs | Implements ICLRSymbolProvider on the legacy-DAC data target CCW and forwards symbol queries to a managed provider. |
| src/Microsoft.Diagnostics.DebugServices.Implementation/ServiceManager.cs | Forces module initializers to run when registering an extension assembly. |
| src/Microsoft.Diagnostics.DebugServices.Implementation/RuntimeProvider.cs | Supplies DataTargetOptions.SymbolProvider from the host service container when creating ClrMD DataTarget. |
| src/Microsoft.Diagnostics.DebugServices.Implementation/Runtime.cs | Centralizes flavor→RuntimeType mapping and adds a CDAC fallback path in GetDacFilePath. |
| src/Microsoft.Diagnostics.DebugServices.Implementation/HostSymbolProvider.cs | New adapter implementing ClrMD’s IClrSymbolProvider on top of IModuleService/IModuleSymbols. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
max-charlamb
force-pushed
the
max-charlamb/symbol-provider
branch
from
5305ad6 to
2294a55
Compare
leculver
reviewed
Jun 17, 2026
leculver
left a comment
leculver
left a comment
Contributor
There was a problem hiding this comment.
Will take a look again tomorrow, just a quick skim so far.
max-charlamb
force-pushed
the
max-charlamb/symbol-provider
branch
from
1399735 to
94e90fc
Compare
Adds an IClrSymbolProvider adapter (HostSymbolProvider) over the host's IModuleService/IModuleSymbols, registered as a per-target service. Wires it into ClrMD via DataTargetOptions.SymbolProvider and exposes it through SOS's legacy-DAC data target CCW (DataTargetWrapper.ICLRSymbolProvider) so both data access paths resolve symbols through one implementation. Also refactors the ClrFlavor -> RuntimeType mapping into a single GetRuntimeType helper and adds NativeAOT to the mapping. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
max-charlamb
force-pushed
the
max-charlamb/symbol-provider
branch
from
94e90fc to
bda0c32
Compare
lateralusX
approved these changes
Jun 23, 2026
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
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.
Requires: microsoft/clrmd#1482
Plumbs ClrMD's IClrSymbolProvider hook through the diagnostics host so the (c)DAC can map runtime addresses back to module-qualified symbols via the host's IModuleService / IModuleSymbols. Also unifies SOS's existing legacy-DAC symbol-provider thunks onto the same shared adapter.
HostSymbolProvider (new): IClrSymbolProvider adapter over IModuleService; registered as a per-target service via [ServiceExport].
RuntimeProvider: sets DataTargetOptions.SymbolProvider from the registered service so ClrMD's COM data target wrapper forwards ICLRSymbolProvider calls to the host.
SOS.Hosting/DataTargetWrapper: exposes ICLRSymbolProvider on the legacy-DAC CCW (was missing), delegating to the same IClrSymbolProvider service for a single resolver code path.
Runtime: extracts the ClrFlavor -> RuntimeType mapping into a single GetRuntimeType helper; adds a generic GetDacFilePath fallback so runtimes that ship only a cDAC (no legacy DAC binary) load via the cDAC without the user having to set ForceUseContractReader.
ServiceManager: invokes RuntimeHelpers.RunModuleConstructor on each loaded extension so module initializers fire at load time, allowing extensions to register process-wide state (e.g. ClrMD IClrInfoProvider) before any provider factory is invoked.
Depends on a ClrMD package that contains IClrSymbolProvider and DataTargetOptions.SymbolProvider (microsoft/clrmd PR pending; the corresponding package-version bump in eng/Version.Details.xml will land via darc once the upstream PR merges).