R2RGetEntryPoint ETW / eventpipe event missing a size

[vvuk]

On Windows, when coreclr loads R2R-built jit assemblies are loaded, symbols from them can be resolved using PDB files and everything works fine. On macOS (and probably linux, since they share the same code), PreJIT symbols are emitted into jitdump files with PerfMapEnabled=1 (but not perfmap files, which is also odd).

Using eventpipe, MethodLoad[Verbose] events are not emitted for for R2R symbols. This is a little annoying, but it matches Windows behaviour. However, there are R2RGetEntryPoint events that are emitted with the compiler diagnostics keyword. These events have almost all the info I need... except the method native code size. As-is, the data in these events gives roughly the same info as a basic symbol map. For every R2RGetEntryPoint, I could look up what native library is mapped at that address and add it to my in-memory symbol map, and then on library unload/process end take all the symbols and infer sizes based on next symbol/end-of-mapping. This is kind of a pain.

I believe the size is available using the same approach that PerfMap::LogPreCompiledMethod uses:

    // Get information about the NGEN'd method code.
    EECodeInfo codeInfo(pCode);
    _ASSERTE(codeInfo.IsValid());

    IJitManager::MethodRegionInfo methodRegionInfo;
    codeInfo.GetMethodRegionInfo(&methodRegionInfo);

if this is true, are people open to a V1 of the R2RGetEntryPoint event that adds a code size? This would mean that the V0 event would no longer be emitted, so PerfView and others may be impacted, though I'm not sure if they're doing anything specific with this event.

R2RGetEntryPoint also doesn't include info about separate hot/cold precompiled code (there's only one method start address, so I assume only the hot address gets reported). Maybe a better approach would be adding a new event, R2RMethodLoad, that looks something like...

                        <data name="MethodID" inType="win:UInt64" outType="win:HexInt64" />
                        <data name="MethodNamespace" inType="win:UnicodeString" />
                        <data name="MethodName" inType="win:UnicodeString" />
                        <data name="MethodSignature" inType="win:UnicodeString" />
                        <data name="MethodStartAddress" inType="win:Pointer" />
                        <data name="MethodSize" inType="win:UInt32" />
                        <data name="MethodColdStartAddress" inType="win:Pointer" />
                        <data name="MethodColdSize" inType="win:UInt32" />
                        <data name="ClrInstanceID" inType="win:UInt16" />

[vvuk]

I could look up what native library is mapped at that address

An update.. I can't do this. I thought there was an actual native library but there isn't; it looks like the r2r compiled code is just in the original assembly? There's no event that provides any mapping/memory region info that I can find.

[dotnet-policy-service]

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

[tommcdon]

@noahfalk @davmason

[davmason]

Adding @brianrob

Hi @vvuk - on non-windows platforms we use alternative ways to get the symbol information for R2R code. You should not have to introduce a new event to the runtime.

The perfcollect tool uses crossgen /CreatePerfMap to generate perfmaps from R2R images, and following that example would be your best bet.

[noahfalk]

@vvuk - I believe a typical way that ETW/EventPipe based profilers would access this data is via rundown events (https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/eventtrace.cpp#L5091-L5117). The terminology is still confusingly labeled as NGen methods, but it is actually enumerating R2R methods on CoreCLR. The rundown events aren't documented much but all the event manifest info is in ClrEtwAll.man. You could look for the MethodDCEnd and MethodDCEndVerbose events on the rundown provider using the NGenRundownKeyword.

The approach David suggested does also work but you might find rundown events easier to work with. There are no external dependencies and the events should work uniformly on any platform where ETW/EventPipe is supported.

[brianrob]

@vvuk, can you share a bit more about the scenario? Both @davmason and @noahfalk have mentioned options that could potentially work, but knowing a bit more about what you are trying to do would help me.

[vvuk]

You could look for the MethodDCEnd and MethodDCEndVerbose events on the rundown provider using the NGenRundownKeyword.

Ah ha! I was aware of the rundown provider (and am using it for some things) but I didn't consider pulling the method info from there. It looks like this should have what I need. I'll try this and will report/close if this is sufficient.

@vvuk, can you share a bit more about the scenario? Both @davmason and @noahfalk have mentioned options that could potentially work, but knowing a bit more about what you are trying to do would help me.

Yep, working on building/improving CoreCLR support into an open-source profiler that can handle both native + managed profile data. The core profiling works, but I'm working to add GC and other data on non-Windows and so am switching to eventpipe; I wanted to move everything to eventpipe instead of relying on jitdump/perfmap data so that I could support attach-to-process.

[brianrob]

You could look for the MethodDCEnd and MethodDCEndVerbose events on the rundown provider using the
Yep, working on building/improving CoreCLR support into an open-source profiler that can handle both native + managed profile data. The core profiling works, but I'm working to add GC and other data on non-Windows and so am switching to eventpipe; I wanted to move everything to eventpipe instead of relying on jitdump/perfmap data so that I could support attach-to-process.

Gotcha, thanks. Hopefully those rundown events will do what you want. These are a historic artifact from before NGEN on .NET Framework could generate PDBs, and so they should act just like their JIT counterparts, assuming that they function properly for R2R code.