NativeAOT under CoreCLR debug experience

[kant2002]

Is there a way how NativeAOT application can be run under CoreCLR. I thinking about substitution of CoreLib for example, and other supplementary technology. That allow have great debug experience and at the same time would be closer to NativeAOT runtime, because WinDBG is not fun to debug your apps.

Is this something worth having?

[MichalStrehovsky]

Do you mean for debugging end user apps, or for inner loop when working on NativeAOT components.

For end user apps, we rely on static analysis: static analysis of both trimming and AOT friendliness. If there's no warnings, there should be nothing to NativeAOT specific to debug because the behavior is going to be same with or without NativeAOT. The aim for NativeAOT apps is to be warning free.

Note the end user workflow assumes you set <PublishAot>true</PublishAot> in your project. This in turn disables a bunch of things in corelib (such as binary serialization) that don't work well with trimming. You should see them disabled when dotnet run the app as well (we do emulate trimming that way at runtime).

because WinDBG is not fun to debug your apps.

I debug Native AOT apps in VS. The native debugger works fine.

[kant2002]

I was thinking more about inner loop, but if things go south for NativeAOT you are in the inner loop.
Do you see variables and can perform deep object inspection and expression evaluation?

[MichalStrehovsky]

You can see variables and perform object inspection. The gotcha is that properties don't work so you're left with the backing fields.

I don't think it would be feasible for CoreCLR to run with NativeAOT CoreLib. Maybe a couple years from now. Maybe.

[kant2002]

I try run under VS and even Reflection-free looks nice. I probably have to change habits to fully form opinion. Regarding waiting. I think I can wait couple years because that's my estimation for maturity of NativeAOT and I have plenty of room to improve things.

[agocke]

At the moment we plan to continue with the native debugging experience, adding new scenarios as we analyze the cost/benefit tradeoff and get more feedback.

I'll close this for now as it's too general. We'd be more interested in specific debugging feature requests.