-
Notifications
You must be signed in to change notification settings - Fork 5.2k
getHelperFtn support for getting CORINFO_METHOD_HANDLE #116603
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
getHelperFtn support for getting CORINFO_METHOD_HANDLE #116603
Conversation
davidwrighton
commented
Jun 12, 2025
- If there is one associated, we will get the method handle. This is an optional parameter, as is the logic to get the existing result.
- This will be used in the interpreter to generate different bytecode that knows about calling managed methods when needed
- There is also some prior interest from the JIT team about using such an api, but it didn't quite get in. See PR Add pMethod param to getHelperFtn EE-JIT API #110267. This PR takes the comment from @jkotas into account to adjust the signature of the method to be something which is simpler and easier to understand
- If there is one associated, we will get the method handle. This is an optional parameter, as is the logic to get the existing result. - This will be used in the interpreter to generate different bytecode that knows about calling managed methods when needed - There is also some prior interest from the JIT team about using such an api, but it didn't quite get in. See PR dotnet#110267. This PR takes the comment from @jkotas into account to adjust the signature of the method to be something which is simpler and easier to understand
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR updates the JIT interface helper functions to support retrieving the CORINFO_METHOD_HANDLE and native entry point via a new API signature. Key changes include:
- Changing the getHelperFtn signature in several headers and implementations from returning a void* to using output parameters (CORINFO_CONST_LOOKUP and CORINFO_METHOD_HANDLE).
- Propagating the new API usage across various JIT components and code generators.
- Adjusting call sites to handle the new lookup structure and access type semantics.
Reviewed Changes
Copilot reviewed 31 out of 31 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| src/coreclr/tools/aot/jitinterface/jitinterface_generated.h | Updated getHelperFtn signature to include native entrypoint and method handle. |
| src/coreclr/tools/Common/JitInterface/ThunkGenerator/ThunkInput.txt | Modified helper function parameter types to use REF_CORINFO_CONST_LOOKUP. |
| src/coreclr/jit/CorInfoImpl_generated.cs | Adjusted managed wrapper for getHelperFtn to match new signature. |
| src/coreclr/jit/CorInfoImpl.cs | Updated managed implementation of getHelperFtn using the new API. |
| src/coreclr/jit/lower.cpp, importer.cpp, compiler.* | Updated call sites for helper functions to use CORINFO_CONST_LOOKUP instead of raw pointers. |
| src/coreclr/jit/codegen*.* | Updated helper lookup usage across various code generators. |
| src/coreclr/inc/* | Updated declarations for getHelperFtn in the EE interface definition. |
| { | ||
| params.addr = nullptr; | ||
| assert(helperFunction.accessType == IAT_PVALUE); | ||
| void* pAddr = helperFunction.addr; |
Copilot
AI
Jun 12, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The variable 'pAddr' is declared in the else block but never used. Removing this redundant declaration would improve code clarity.
| { | ||
| params.addr = nullptr; | ||
| assert(helperFunction.accessType == IAT_PVALUE); | ||
| void* pAddr = helperFunction.addr; |
Copilot
AI
Jun 12, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The redundant declaration of 'pAddr' in the else branch is not used; consider removing it to simplify the code.
| void* pAddr = helperFunction.addr; |
| // If we don't have a matched VM, we won't get valid results when asking for a helper function. | ||
| addr = (void*)(uintptr_t)(0xCA11CA11); // "callcall" | ||
| lookup.addr = (void*)(uintptr_t)(0xCA11CA11); // "callcall" | ||
| lookup.accessType = IAT_VALUE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we add a new IAT_ enum for 'nothing' so that anything that switch()es on the accessType will fail fast?
|
|
||
| [UnmanagedCallersOnly] | ||
| private static void* _getHelperFtn(IntPtr thisHandle, IntPtr* ppException, CorInfoHelpFunc ftnNum, void** ppIndirection) | ||
| private static void _getHelperFtn(IntPtr thisHandle, IntPtr* ppException, CorInfoHelpFunc ftnNum, CORINFO_CONST_LOOKUP* pNativeEntrypoint, CORINFO_METHOD_STRUCT_** pMethod) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this makes me wonder whether it should be called ppMethod instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, not really... a method is a CORINFO_METHOD_STRUCT_* ... the first pointer is just part of being a method. This is just messy interop things, since we couldn't use a normal struct here to represent a typedef, since pointers and structs that only have a pointer in them are represented differently in the native ABI on some platforms. @max-charlamb recently talked to @jkoritzinsky and we now have an actual clean way to represent this using the p/invoke source generator (this is the CustomMarshalerAttribute support), but this logic predates that feature by several years.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah at some point we should be able to move to source-gen interop for this. Would require us to productize our "vtables but not COM" generator though (or make the JIT-EE interface build off of IUnknown just enough for the COM generator to interface well).
| Packet_NotifyInstructionSetUsage = 229, | ||
| Packet_GetAsyncInfo = 230, | ||
| Packet_GetAsyncResumptionStub = 231, | ||
| Packet_GetHelperFtn = 233, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that if you change the size of contents of the data packet in SPMI you need a new magic number. See MethodContext::MethodInitHelper. Since this PR changes the definition of what the LWM map for GetHelperFtn is, I updated the magic value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not needed -- the JIT-EE GUID update is sufficient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would also be nice to fix the wrong type added in #116449 (comment) (since you're going to have to resolve merge conflicts anyway...)
|
LGTM overall |
|
Bumping JIT-EE guid is hot these days 🙂 |
|
Tagging @dotnet/jit-contrib for JIT-EE GUID update |
| else | ||
| // We never return a method handle from the managed implementation of this method today | ||
| if (pMethod != null) | ||
| *pMethod = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will want to fix this if/once JIT starts doing helper inlining. cc @EgorBo
a6513e3 is being scheduled for building and testingGIT: |
|
@dotnet/samsung |
|
/ba-g these failures are known and unrelated |