Uh oh!
There was an error while loading. Please reload this page.
Preserve IL for CoreCLR interpreter fallback on Apple mobile - #130622
Conversation
Tagging subscribers to this area: @dotnet/runtime-infrastructure |
Co-authored-by: kotlarmilos <11523312+kotlarmilos@users.noreply.github.com>
Co-authored-by: kotlarmilos <11523312+kotlarmilos@users.noreply.github.com>
kotlarmilos
commented
Jul 13, 2026
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Uh oh!
There was an error while loading. Please reload this page.
jkotas
commented
Jul 13, 2026
This sounds like a bug in how we produce the R2R images for use with interpreter. The instruction set should be fixed in this case, and we should never reject the native code. If the actual machine supports more instruction set extensions that the fixed set, we should ignore them. |
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 19812166-4b05-40cc-9a81-8b80b909e10b
kotlarmilos
commented
Jul 21, 2026
/azp run runtime-extra-platforms |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Copilot's findings
Comments suppressed due to low confidence (2)
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCasesRunner/R2RResultChecker.cs:977
- EagerInstructionSetSupportHasNoUnsupportedEntries claims to validate the global eager baseline Check_InstructionSetSupport fixup, but it currently scans all import sections (including non-eager/method-level sections). This can produce false failures if any per-method Check_InstructionSetSupport signatures contain '-' entries.
Filter to eager import sections (ReadyToRunImportSectionFlags.Eager) to match the method's stated intent.
foreach (ReadyToRunImportSection section in reader.ImportSections)
{
if (section.Entries is null)
continue;
foreach (ReadyToRunImportSection.ImportSectionEntry entry in section.Entries)
{
if (entry.Signature is not null && entry.Signature.FixupKind == ReadyToRunFixupKind.Check_InstructionSetSupport)
signatures.Add(entry.Signature.ToString(options));
}
}
src/libraries/System.Reflection.Metadata/tests/Metadata/Decoding/SignatureDecoderTests.cs:266
- The stripped-IL detection uses raw opcode bytes (0x2A and 0xFE 0x24) without explaining what 0xFE 0x24 represents. Adding a brief comment (and a named constant for 0x2A) would make it clearer that this matches the crossgen2 IL-stripping sentinel (CopiedMethodILNode.s_minimalILBody).
var il = body.GetILBytes();
bool isStripped =
(il?.Length == 1 && il[0] == 0x2A) ||
(il?.Length == 2 && il[0] == 0xFE && il[1] == 0x24);
if (!isStripped)
- Files reviewed: 13/13 changed files
- Comments generated: 0 new
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
crossgen2 binaries are host-specific, so gating GetTargetAllowsRuntimeCodeGeneration on the host build's FEATURE_DYNAMIC_CODE_COMPILED define is wrong. Drop the define from crossgen2.props and the surrounding #if from Program.cs, leaving the decision purely on the target OS and architecture. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2d421224-6ce0-4d3a-92ac-263330249e7c
…yToRun The define is no longer consumed by any source in the project after the runtime-codegen decision moved to a target-based check in crossgen2. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2d421224-6ce0-4d3a-92ac-263330249e7c
kotlarmilos
commented
Jul 22, 2026
/azp run runtime-extra-platforms |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
kotlarmilos
commented
Jul 28, 2026
/ba-g Libraries x86 Debug is #130947, extra-platforms failures overlap with main |
Uh oh!
There was an error while loading. Please reload this page.
am11
commented
Jul 28, 2026
This conflicted with #131429.
|
kotlarmilos
commented
Jul 29, 2026
Thanks for the heads up, should be fixed in #131505. @lewing Thanks! |
Apple mobile composite ReadyToRun publishing could strip IL later required by the CoreCLR interpreter when compiled code is rejected or unavailable in a custom load context.
Stripping policy
Coverage