[cDAC] Add switch to load cDAC directly

[max-charlamb]

Depends on cDAC changes dotnet/runtime#113899

• Adds ICLRContractLocator COM interface which is passed to DAC/cDAC instantiation. Fetches the contract descriptor location. New cDAC entrypoint depends on this API.
• Managed path (SOS.Hosting)
  • Loads cDAC if DOTNET_SOS_LOAD_CDAC is set
  • Implements ICLRContractLocator using existing IExportSymbol service
• Native path
  • Loads cDAC if DOTNET_SOS_LOAD_CDAC is set
  • Lays out interface but does not implement ICLRContractLocator. The existing symbol lookup defers to WinDBG for Windows and uses parsers for MachO/ELF. However, only one of these is built at a time depending on the host platform. Todo: figure out cross-platform native symbol reading.

[mikem8361]

I was planning to do this work myself later this week or next. This PR does have some considerable issues like all the code changes under "Strike\platform" are only used to fallback when there isn't a managed host. We use the CLRMD runtime enumeration to find a "runtime" and to create the IXCLRDataProcess instance for managed code.

And using an env var to control loading the CDAC isn't the direction I want to go in. I haven't completely thought this out but the !runtime command can be used to control this. And we may want to have the CLRMA code use the CDAC and the rest of SOS to still use the regular DAC.

[mikem8361]

I'm not saying most of this work will be needed like adding ICLRContractLocator and the implementation.

[max-charlamb]

I was planning to do this work myself later this week or next. This PR does have some considerable issues like all the code changes under "Strike\platform" are only used to fallback when there isn't a managed host. We use the CLRMD runtime enumeration to find a "runtime" and to create the IXCLRDataProcess instance for managed code.

And using an env var to control loading the CDAC isn't the direction I want to go in. I haven't completely thought this out but the !runtime command can be used to control this. And we may want to have the CLRMA code use the CDAC and the rest of SOS to still use the regular DAC.

Agreed on the env variable. A command would be preferable.

I was looking into the difference between managed/native hosting and have tested this on Windows-x64 for the managed hosting. The native hosting I set up some interfaces but didn't implement ICLRContractLocator because it is unclear to me how to get cross-platform symbol reading.

We can discuss this tomorrow at the cDAC meeting. I'm happy to change this how you prefer or drop part of it.

[mikem8361]

FYI, this should use the RuntimeInformation.IsOSPlatform() because we need the OS we are loading the module on not the target OS. We can load Linux dumps on Windows with windbg or dotnet-dump.

[mikem8361]

Probably will just add another value to DebugLibraryKind for the CDAC in CLRMD. CLRMD needs some of these changes and more to find a CDAC compatible runtime, load it and create the instance.