[cDAC] GetConstructedType cannot resolve cross-module pointer TypeDescs

[max-charlamb]

Summary

RuntimeTypeSystem_1.GetConstructedType fails to find pointer TypeDescs (e.g., int*) when the TypeDesc lives in a different module than the element type's loader module. This causes ClrDataFrame to return DEFAULT flags for pointer variables instead of IS_POINTER.

Root Cause

GetConstructedType searches only the loader module's AvailableTypeParams hash table:

1. For int*, GetLoaderModule(int) returns CoreLib
2. The search iterates CoreLib's AvailableTypeParams via GetAvailableTypeParams(CoreLib)
3. If the int* TypeDesc was allocated in the debuggee's module (not CoreLib), it won't be found

The native runtime uses ComputeLoaderModule(TypeKey) -> LookupInLoaderModule -> EETypeHashTable::GetValue(TypeKey*) which performs a hash-based lookup in the computed loader module. The native DAC can find the TypeDesc because it traverses the actual runtime type system data structures.

Affected Code

• cDAC: src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/RuntimeTypeSystem_1.cs GetConstructedType method (line ~851)
• Consumer: src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/ClrDataFrame.cs CreateValueFromDebugInfo (line ~500)
• Native reference: src/coreclr/vm/clsload.cpp ClassLoader::LoadConstructedTypeThrowing / LookupInLoaderModule

The TODO is in ClrDataFrame.cs:

// TODO: Implement cross-module TypeDesc search in GetConstructedType
// so that pointer types (ELEMENT_TYPE_PTR) can be resolved even when
// their TypeDesc lives in a different module than the element type.
valueFlags = (uint)ClrDataValueFlag.DEFAULT;

Possible Approaches

1. Implement ComputeLoaderModule logic in the cDAC to match the native runtime's module computation, ensuring the correct module is searched
2. Search multiple modules if the loader module search fails (fallback to searching all loaded modules' AvailableTypeParams)
3. Use hash-based lookup instead of linear scan in GetAvailableTypeParams if the EETypeHashTable structure supports key-based queries from the cDAC

Impact

Pointer variable arguments (int*, char*, etc.) in stack frames will have DEFAULT (0x0) flags instead of IS_POINTER (0x00040000). This affects diagnostic tools that inspect variable types via IXCLRDataValue::GetFlags. Function pointers (delegate*) are not affected because the cDAC maps FNPTR to IntPtr (matching native DAC behavior).

/cc @max-charlamb

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[jkotas]

If the int* TypeDesc was allocated in the debuggee's module (not CoreLib), it won't be found

int* TypeDesc is always going to be allocated in CoreLib.

I think the problem is that some of the debugger APIs depend on the types being loaded by the runtime, but the runtime may not always have a reason to load those types. Historically, we have hacked around this by finding a good spot to load the types just to make debugger happy. This is not great for startup performance, and it is inherently fragile.

The right design is that debuggers create virtual types in this situation without requiring the types to be loaded by the runtime. This sort of virtualization belongs to higher level debugger. Visual Studio debugger is able to do that to some degree today.

[max-charlamb]

I found this while verifying #125463, see the debuggee I created with stackframes that exercise different types of variables. I thought the int* type would have been loaded since the function is on the stack. https://github.com/dotnet/runtime/pull/125463/changes#diff-b81458cf14531ec85ae9a55958bf427d83aaca31b3ce3374915b920c40c9973d

[jkotas]

These is nothing that requires the runtime to fully load types for all types in the method signatures. If the runtime sees that the argument is pointer, it is often all it needs. It does not need to know the exact type of the pointer in the typical case.

I think https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/jitinterface.cpp#L9700-L9712 is the hack that makes the pointer case "work" for non-optimized code.

[max-charlamb]

I see, is there a preferred way you'd like to deal with this in the cDAC? We can read the signature directly to find the type without going through the IRuntimeTypeSystem TypeHandle infrastructure.

[jkotas]

read the signature directly to find the type

What is the type representation you are going to find this way?

I do not think that the full type virtualization belongs to cDAC. The cDAC should just return the raw signature (tokens, etc.) to higher levels.

I understand that some of the DAC and CorDebug APIs are designed with assumption that the type is loaded by the runtime. I think it is bad design and we want to deprecate those APIs. (We can keep them as broken as they are today - only return the type if it happens to be loaded by the runtime.)

[max-charlamb]

This particular API IXClrDataValue::GetFlags, only requires knowing if it IS_POINTER.

The current IRuntimeTypeSystem fails loading the full type but does know that it is a pointer. I can either ad-hoc read the method signature or add support to IRuntimeTypeSystem to partially resolve a type.

[jkotas]

ad-hoc read the method signature

I think this will work better.