[dotnet-linker] Work around a crossgen2 crash compiling the trimmable-static type maps - #26345
Conversation
…-static type maps
The types named by our type-map entries only show up in the custom attribute
blobs, as assembly-qualified names. Nothing else in the generated type map
assembly refers to them from IL, so Cecil doesn't emit a TypeRef row for them.
That's valid metadata: ECMA-335 II.23.3 only requires a System.Type custom
attribute argument to be stored as a SerString holding the type's canonical name,
and neither the CustomAttribute (II.22.10) nor the TypeRef (II.22.38) validity
rules require a matching TypeRef row. The runtime agrees - it resolves these
types by parsing the string, not by looking at the TypeRef table - and the type
map design explicitly says the assembly name in TypeMapAssemblyTargetAttribute
doesn't need a matching AssemblyRef row either.
crossgen2 nonetheless assumes the TypeRef row is there. It fails all four lookups
in ModuleTokenResolver.GetModuleTokenForType (the type doesn't version with the
compilation, there's no TypeRef in the input, and nothing has added it to the
manifest module), and falls through to a bare
`throw new NotImplementedException (type.ToString ())`, so ReadyToRun-compiling
an app with the trimmable-static registrar fails:
System.NotImplementedException: [Microsoft.macOS]UserNotificationsUI.IUNNotificationContentExtension
at ILCompiler.DependencyAnalysis.ReadyToRun.ModuleTokenResolver.GetModuleTokenForType(TypeDesc, Boolean, Boolean)
at ILCompiler.DependencyAnalysis.ReadyToRun.SignatureContext.GetTargetModule(TypeDesc)
at ILCompiler.DependencyAnalysis.ReadyToRun.TypeFixupSignature.GetData(NodeFactory, Boolean)
at ILCompiler.DependencyAnalysis.ReadyToRun.ImportSectionNode.MaterializeSignature(NodeFactory)
at ILCompiler.DependencyAnalysis.ReadyToRun.ManifestMetadataTableNode.ComputeLastSetOfModuleIndices()
at ILCompiler.DependencyAnalysis.ReadyToRun.ManifestAssemblyMvidHeaderNode.GetData(NodeFactory, Boolean)
Work around it by adding an unused method to each generated type map assembly
that does an `ldtoken` for every externally defined type the maps name. That's
enough for Cecil to emit the TypeRef rows, and crossgen2 then resolves the types
through `TryGetModuleTokenForExternalType`. `ldtoken` is used rather than a field
or parameter because it also works for open generic types. The method is never
called, so it's trimmed away again by ILLink.
Only CoreCLR needs this, so the other runtimes don't pay for it. In particular
NativeAOT app size is unaffected (bit-for-bit identical). For CoreCLR it adds
~64 KB per runtime identifier to the platform type map assembly.
Reported upstream as dotnet/runtime#131527, and tracked
for removal in #26343.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 6aeeddfd-3bd8-4129-ad90-7292860c4b66
The workaround emits TypeRef rows for every type map entry into the generated type map assemblies when using CoreCLR, which makes those assemblies (and thus the app) slightly bigger. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 6aeeddfd-3bd8-4129-ad90-7292860c4b66
The previous commit was generated on a local machine whose build produces a slightly different Info.plist / Microsoft.macOS.dll / executable than CI does (a pre-existing ~5.9 KB difference that also shows up in the unmodified CoreCLR_Interpreter test). Keep only the delta actually caused by this change: +64,000 bytes per RID in the generated type map assembly. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 6aeeddfd-3bd8-4129-ad90-7292860c4b66
Two different assemblies can contain types with the same full name, in which case deduplicating on the full name alone would skip a TypeRef we need. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 6aeeddfd-3bd8-4129-ad90-7292860c4b66
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Pull request overview
This PR adds a targeted workaround in the trimmable-static type map generation step to prevent a crossgen2 ReadyToRun crash when compiling the generated type map assemblies. The workaround forces Mono.Cecil to emit TypeRef metadata rows for types that otherwise only appear inside custom attribute blobs.
Changes:
- Emit an unused method that
ldtokens all externally-scoped types referenced by type map custom attributes (CoreCLR only), ensuringTypeRefrows exist for crossgen2. - Invoke the new emission step during per-assembly type map assembly generation.
- Update the macOS CoreCLR interpreter trimmable-static app size baseline to account for the increased type map assembly size.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| tools/dotnet-linker/Steps/TrimmableRegistrarStep.cs | Adds CoreCLR-only emission of ldtoken references to force TypeRef rows and avoids crossgen2 crash when compiling type map assemblies. |
| tests/dotnet/UnitTests/expected/MacOSX-CoreCLR-Interpreter-TrimmableStatic-size.txt | Updates expected bundle/type map assembly sizes after the additional metadata. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ API diff for current PR / commitNET (empty diffs)✅ API diff vs stableNET (empty diffs)ℹ️ Generator diffGenerator Diff: vsdrops (html) vsdrops (raw diff) gist (raw diff) - Please review changes) Pipeline on Agent |
🚀 [CI Build #0566dd8] Test results 🚀Test results✅ All tests passed on VSTS: test results. 🎉 All 203 tests passed 🎉 Tests counts✅ assembly-processing: All 1 tests passed. Html Report (VSDrops) Download macOS tests✅ Tests on macOS Monterey (12): All 5 tests passed. Html Report (VSDrops) Download Linux Build VerificationPipeline on Agent |
The types named by our type-map entries are only mentioned in the custom attribute blobs (as assembly-qualified names), so the generated type map assembly ends up without a
TypeRefrow for them.crossgen2 assumes such a
TypeRefrow exists: it can't resolve the type back to a module token and crashes with aNotImplementedExceptioninModuleTokenResolver.GetModuleTokenForTypewhen it ReadyToRun-compiles the type map assembly.Upstream issue: dotnet/runtime#131527
Tracking issue to remove this workaround: #26343
Is our metadata valid?
Yes — this is a crossgen2 bug, not a Cecil bug:
System.Typeargument is stored as aSerStringholding the canonical name. Nothing more.TypeRefrow.Ecma-335-Augments.mdtypemap.md(runtime design doc)AssemblyRefrow".The runtime itself resolves these types by parsing the string, not via the
TypeReftable.The workaround
Emit an unused
<TypeReferences>.KeepTypeReferencesmethod into the type map assembly thatldtokens every externally defined type we name. That makes Cecil emit the correspondingTypeRefrows. The method is never called, so ILLink trims it away again.This is scoped to CoreCLR — NativeAOT and MonoVM don't need it, and the extra metadata isn't free. It is deliberately not narrowed further to ReadyToRun-only builds, because ReadyToRun for CoreCLR is a .NET 11+ feature and that would mean the code behaves differently between branches; the cost for the interpreted CoreCLR configurations is small (~64 KB per runtime identifier in the platform type map assembly).
App size impact
Only the CoreCLR + trimmable-static configuration changes:
MacOSX-CoreCLR-Interpreter-TrimmableStaticgrows by 128,000 bytes (2 RIDs × 64,000 bytes). All NativeAOT and MonoVM sizes are unchanged (verified:tests-dotnet NativeAOTreports ≤5 bytes of drift across all 8 NativeAOT configs).🤖 Pull request created by Copilot