Missing some compilation information for generic methods

[ashmind]

Hi -- thanks for the great library.
I've noticed an issue with finding assembly size and compilation state on some generic methods.

I have a (test) generic method that looks like this:

static class C {
    static T M<T>() {
        return default(T);
    }
}

I got a M<int> as MethodInfo, and have its method handle, let's say 0x00007ff98e4ccfc0.
The method is jitted.

I have then saved a minidump.

If I open that minidump in WinDbg:

0:009> !DumpMD 0x00007ff98e4ccfc0
Method Name:          C.M[[System.Int32, System.Private.CoreLib]]()
Class:                00007ff98e4ccc18
MethodTable:          00007ff98e4ccd30
mdToken:              0000000006000001
Module:               00007ff98e4cc080
IsJitted:             yes
Current CodeAddr:     00007ff98e4c0480
Version History:
  ILCodeVersion:      0000000000000000
  ReJIT ID:           0
  IL Addr:            000001eb35e30250
     CodeAddr:           00007ff98e4c0480  (Optimized)
     NativeCodeVersion:  0000000000000000

0:009> !U 0x00007ff98e4ccfc0
Normal JIT generated code
C.M[[System.Int32, System.Private.CoreLib]]()
ilAddr is 000001EB35E30250 pImport is 0000021DA60103A0
Begin 00007FF98E4C0480, size 3
00007ff9`8e4c0480 33c0            xor     eax,eax
00007ff9`8e4c0482 c3              ret

As you can see, IsJitted: yes and it can identify code size as size 3.

However if I do this in ClrMD (2.0.226801):

using System;
using System.Linq;
using Microsoft.Diagnostics.Runtime;

var dataTarget = DataTarget.LoadDump("_path_to_dump_.dmp");
var runtime = dataTarget.ClrVersions.Single(c => c.Flavor == ClrFlavor.Core).CreateRuntime();

var clrMethod = runtime.GetMethodByHandle(0x00007ff98e4ccfc0);

Console.WriteLine($"Name: {clrMethod.Name}");
Console.WriteLine($"Compilation Type: {clrMethod.CompilationType}");
Console.WriteLine($"Hot Start: 0x{clrMethod.HotColdInfo.HotStart:X}");
Console.WriteLine($"Hot Size: {clrMethod.HotColdInfo.HotSize}");

I get

Name: CoreLib]]
Compilation Type: None
Hot Start: 0x7FF98E4C0480
Hot Size: 0

Issues:

1. I would expect CompilationType to be Jit (I know method is jitted, and WinDbg gives IsJitted: yes)
2. Hot Size is 0, but WinDbg was able to identify the size as 3 -- it would be great to get the same info here
3. Method name looks truncated (probably a separate issue, but just wanted to mention)

[ashmind]

I did some more investigation.
Current logic in ClrMD is to grab the header based on the slot:

clrmd/src/Microsoft.Diagnostics.Runtime/src/Builders/MethodBuilder.cs

Lines 36 to 37 in 11f8c12

	ulong slot = sos.GetMethodTableSlot(_mdData.MethodTable, _mdData.SlotNumber);
	return sos.GetCodeHeaderData(slot, out _codeHeaderData);

Somehow I suspect it might be grabbing the generic method definition from the method table, instead of the compiled generic instantiation.

I tried this:

sos.GetMethodDescData(0x00007ff98e4ccfc0, 0, out var sosMethodDesc);

// Current logic in ClrMD -- does this pick up generic method definition by any chance?
var slot = sos.GetMethodTableSlot(sosMethodDesc.MethodTable, sosMethodDesc.SlotNumber);
sos.GetCodeHeaderData(slot, out var slotBasedHeaderData);

Console.WriteLine($"Slot: 0x{slot:X}");
Console.WriteLine($"Slot-based JIT Type: {slotBasedHeaderData.JITType}");
Console.WriteLine($"Slot-based Hot Size: {slotBasedHeaderData.HotRegionSize}");

// This might work?
sos.GetCodeHeaderData(sosMethodDesc.NativeCodeAddr, out var nativeAddrBasedHeaderData);
Console.WriteLine($"Native Code Addr: 0x{sosMethodDesc.NativeCodeAddr.Value:X}");
Console.WriteLine($"Native-based JIT Type: {nativeAddrBasedHeaderData.JITType}");
Console.WriteLine($"Native-based Hot Size: {nativeAddrBasedHeaderData.HotRegionSize}");

and it outputs

Slot: 0x7FF98E4C0078
Slot-based JIT Type: 0
Slot-based Hot Size: 0

Native Code Addr: 0x7FF98E4C0480
Native-based JIT Type: 1
Native-based Hot Size: 3

To be honest I have very little knowledge on how those are actually stored in memory, so I might be completely off-mark.
But assuming the method table has the original generic definition and assuming the header is stored with the method, this kind of makes sense.

[ashmind]

Hmm, this approach works for value-type generics, but not for reference types.
For reference types original slot-based approach seems to work better (at a glance).

[ashmind]

I ended up with this:

var codeHeaderAddress = methodDesc.HasNativeCode != 0
    ? (ulong)methodDesc.NativeCodeAddr
    : sos.GetMethodTableSlot(methodDesc.MethodTable, methodDesc.SlotNumber);

which seems to work for all my tests

Update:
Might be wrong, still seeing some issues with reference type generics, investigating.

[davidcorbin-atmosera]

Any update on this... looking for reliable way to get native code sizes for all methods...