[mono] FullAOT runtime test failures: Attempting to JIT compile method

[imhameed]

Several runtime tests (which can be found by searching issues.targets for this issue number) fail to pass with this message:

Attempting to JIT compile method '[function name here]' while running in aot-only mode

Tests are run using MONO_ENV_OPTIONS=--full-aot.

FullAOT compilation uses these flags on x64:

MONO_ENV_OPTIONS="--aot=full,llvm,llvm-path=$MONO_PFX,mattr=sse4.2,mattr=popcnt,mattr=lzcnt,mattr=bmi,mattr=bmi2,mattr=pclmul,mattr=aes"

and these on arm64:

MONO_ENV_OPTIONS="--aot=full,llvm,llvm-path=$MONO_PFX,mattr=crc,mattr=crypto"

[lambdageek]

Update I am wrong

Looking at, for example, #80642 which introduced a new testcase that appears to hit this issue, it seems like what is happening is that we need to throw a TypeLoadException during layout of some class, but since we're in the AOT compiler, we're not allowed to run managed code (such as the TLE constructor).

[lambdageek]

Update I think i may have misunderstood what is happening (in at least some of the tests).

It looks like the blanket MonoAotIncompatible property in objrefandnonobjrefoverlap/Directory.Build.prop only stops the AOT compiler from running on the assemblies in the directory. IT doesn't prevent the test from running. So on non-full AOT the test runs, falls back to the JIT (or interp) and maybe passes. On fullAOT, the test tries to run, but since the runtime is set to fail if it tries to fall back to the JIT, the execution fails since there's no AOT image available. So the test fails.

Probably the best we can do here is just improve the diagnostic: instead of attempting to throw a TLE and erroring out (because execution is not allowed) we would detect that we're in the AOT compiler and just print a diagnostic message (ideally mentioning the real issue) and exit.

It might see like a better idea is to succeed in compilation and generate code that when called with throw the TLE, but that actually seems pretty hard. For example if the bad class is used as a method parameter we might not be able to generate anything that is callable - so compilation will appear to succeed but it will crash badly (possibly even more confusingly) if the method is called.

I think we should just improve the AOT compiler error message to report the actual cause.

/cc @SamMonoRT - we should talk about this on our next 1-1

[lambdageek]

We should have a better error message in full AOT mode. Also a better way to skip tests with full AOT than just adding to the issues.targets file