Improvements for DOTNET_JitDisasm, improvement for SOS

[ladeak]

Improvements for DOTNET_JitDisasm, improvement for SOS.

I have a simple ASP.NET Core application:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/", () => "Hello World");
app.Run();

The task I would like to solve: I would like to see the JIT generated assembly code for the anonymous lambda returning Hello World string literal.

Ideally I would like to do it without modifying the source code. (If the anonymous method is named and NoInlining attribute is added, the steps below become trivial, but that is not the case for a production builds of an application.)

Using JIT_Disasm or DOTNET_JitDisasmSummary does not help:

• DOTNET_JitDisasmSummary lists too many methods, and very easy to get lost.
• DOTNET_JitDisasm won't return the method because it is inlined (even if I try to look up its name in the IL).

When I take a memory dump using dotnet-dump for analysis, I can catch a stack trace for the request.

However, it is pointing at a Dynamic.lambda_xzy frame, and when I try to get the assembly code for it with SOS in windbg, the following message is shown instead:

Can only work with dynamic not implemented

What would be the best tool / diagnostic steps to gather a better understanding of the underlying assembly code for the above case?

[hez2010]

It's DOTNET_JitDisasm (case-sensitive) instead of JIT_Disasm. Are you sure you were setting the correct environment variable?

[ladeak]

Thank you for the suggestion, I corrected the description and the title. In practice I have used DOTNET_JitDisasm, so the issue is still the same.

[EgorBo]

I think the simplest option is to wrap your lambda into a non-inlineable method ([MethodImpl(MethodImplOptions.NoInlining)]) so then you can easily find it / request JitDisasm for.

[ladeak]

@EgorBo yes, exactly, but this is only possible after recompiling the app, which I would like to be able to avoid.