Skip to content

ILLink: Stop giving special treatment to icalls #113704

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

mrvoorhe
Copy link
Contributor

As discussed #113437 (comment)

@mrvoorhe mrvoorhe requested a review from marek-safar as a code owner March 19, 2025 18:28
@ghost ghost added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Mar 19, 2025
@dotnet-policy-service dotnet-policy-service bot added linkable-framework Issues associated with delivering a linker friendly framework community-contribution Indicates that the PR has been added by a community member labels Mar 19, 2025
@mrvoorhe
Copy link
Contributor Author

fyi @jkotas @MichalStrehovsky @sbomer

@mrvoorhe mrvoorhe force-pushed the linker-icalls-no-proc-interop branch from 8394dc9 to bad27eb Compare March 19, 2025 18:56
@mrvoorhe mrvoorhe changed the title Stop giving special treatment to icalls ILLink: Stop giving special treatment to icalls Mar 19, 2025
@jkotas
Copy link
Member

jkotas commented Mar 20, 2025

I have taken a look at the coreclr failures. jkotas@6caad79 should fix them. Feel free to cherry-pick this commit to this PR.

@marek-safar marek-safar added the area-Tools-ILLink .NET linker development as well as trimming analyzers label Mar 20, 2025
Copy link
Contributor

Tagging subscribers to this area: @dotnet/illink
See info in area-owners.md if you want to be subscribed.

@jkotas jkotas removed the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Mar 20, 2025
@jkotas
Copy link
Member

jkotas commented Mar 20, 2025

The rest looks like issues with the linker tests and Mono. Let me know if you need help with fixing those.

@agocke agocke requested a review from sbomer March 20, 2025 23:04
Copy link
Member

@sbomer sbomer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM once green, thank you!

For the mono failures, I think we just need to remove the UnconditionalSuppressMessage of IL2110 from RuntimeEnumBuilder and RuntimeTypeBuilder.

@@ -638,10 +638,6 @@ protected override ConstructorBuilder DefineTypeInitializerCore()
null);
}

[UnconditionalSuppressMessage("ReflectionAnalysis", "IL2110:ReflectionToDynamicallyAccessedMembers",
Justification = "For instance member internal calls, the linker preserves all fields of the declaring type. " +
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does the linker know that the Mono unmanaged runtime depends on the RuntimeTypeBuilder fields? Do we need to declare the dependency somewhere?

Copy link
Member

@sbomer sbomer Mar 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only place I'm aware of for mono is via a descriptor (https://github.com/dotnet/runtime/blob/main/src/mono/System.Private.CoreLib/src/ILLink/ILLink.Descriptors.xml).

I see RuntimeTypeBuilder loaded here:

method = mono_class_get_method_from_name_checked (mono_class_get_type_builder_class (), "IsAssignableToInternal", 1, 0, error);

and it looks like the ctor annotations have been set up to preserve fields too:
[DynamicDependency(nameof(state))] // Automatically keeps all previous fields too due to StructLayout
[DynamicDependency(nameof(IsAssignableToInternal))] // Used from reflection.c: mono_reflection_call_is_assignable_to
internal RuntimeTypeBuilder(RuntimeModuleBuilder mb, TypeAttributes attr, int table_idx, bool is_hidden_global_type = false)
{
this.is_hidden_global_type = is_hidden_global_type;
this.parent = null;
this.attrs = attr;
this.class_size = UnspecifiedTypeSize;
this.table_idx = table_idx;
this.tname = table_idx == 1 ? "<Module>" : "type_" + table_idx.ToString();
this.nspace = string.Empty;
this.fullname = TypeIdentifiers.WithoutEscape(this.tname);
pmodule = mb;
}
[UnconditionalSuppressMessage("ReflectionAnalysis", "IL2074:UnrecognizedReflectionPattern",
Justification = "Linker doesn't analyze ResolveUserType but it's an identity function")]
[DynamicDependency(nameof(state))] // Automatically keeps all previous fields too due to StructLayout
[DynamicDependency(nameof(IsAssignableToInternal))] // Used from reflection.c: mono_reflection_call_is_assignable_to
internal RuntimeTypeBuilder(RuntimeModuleBuilder mb, string name, TypeAttributes attr, [DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.All)] Type? parent, Type[]? interfaces, PackingSize packing_size, int type_size, Type? nesting_type)

So I think it would make sense to add an entry for these ctors to the descriptors.

@mrvoorhe
Copy link
Contributor Author

@sbomer Are all of these failures related to this PR? It's hard to tell.

@jkotas
Copy link
Member

jkotas commented Mar 24, 2025

Yes, they look related. Mono Wasm depends on FCalls to be in PInvokesListFile that is no longer happening with this change.

@mrvoorhe
Copy link
Contributor Author

mrvoorhe commented Mar 24, 2025

Yes, they look related. Mono Wasm depends on FCalls to be in PInvokesListFile that is no longer happening with this change.

Gotcha. What do you want to do about that?

@jkotas
Copy link
Member

jkotas commented Mar 24, 2025

Actually, the PInvokesListFile looks fine. But some other dependencies that the MonoVM depends on may be missing - potentially related to #113704 (comment) .

@sbomer sbomer closed this Jul 7, 2025
@sbomer sbomer reopened this Jul 7, 2025
@sbomer
Copy link
Member

sbomer commented Jul 7, 2025

/azp run runtime dotnet-linker-tests

Copy link

Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command.

@sbomer
Copy link
Member

sbomer commented Jul 7, 2025

@mrvoorhe I resolved the merge conflicts in https://github.com/sbomer/runtime/tree/pr/mrvoorhe/113704, feel free to pull in that change.
I think the test failures might need us to add descriptors for RuntimeTypeBuilder and RuntimeEnumBuilder per #113704 (comment).

@mrvoorhe mrvoorhe force-pushed the linker-icalls-no-proc-interop branch from ee5ba2d to dcf9846 Compare July 8, 2025 14:47
@mrvoorhe
Copy link
Contributor Author

mrvoorhe commented Jul 8, 2025

Closing this PR. I pushed a bad set of changes and it pulled in a bunch of reviewers automatically. I'll open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Tools-ILLink .NET linker development as well as trimming analyzers community-contribution Indicates that the PR has been added by a community member linkable-framework Issues associated with delivering a linker friendly framework
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants