Fix clsHnd in impImportCall #93176
Fix clsHnd in impImportCall #93176
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
ghost
assigned 
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
|
/azp list |
This comment was marked as resolved.
This comment was marked as resolved.
|
/azp run runtime-coreclr outerloop, runtime-nativeaot-outerloop |
|
Azure Pipelines successfully started running 2 pipeline(s). |
| clsFlags = callInfo->classFlags; | ||
|
|
||
| // if clsHnd is an interface and method is static, try to get the actual implementation class | ||
| if ((clsFlags & CORINFO_FLG_INTERFACE) != 0 && (clsFlags & CORINFO_FLG_INTERFACE) != 0) |
There was a problem hiding this comment.
There are other situations where getCallInfo can resolve the method to a method on a different class. Would it be better to return the class handle of the resolved method in CORINFO_CALL_INFO?
There was a problem hiding this comment.
(Also, the condition has typo - it checks CORINFO_FLG_INTERFACE twice.)
There was a problem hiding this comment.
@jkotas do you mean getCallInfo should patch input resolveToken->hClass? Because it seems that JIT mostly access hClass directly from resolveToken for methods in importer
There was a problem hiding this comment.
I meant that there should be a new CORINFO_CLASS_HANDLE hClass; //target class handle field in CORINFO_CALL_INFO.
Patching CORINFO_RESOLVED_TOKEN would be a hack. CORINFO_RESOLVED_TOKEN is meant to be "in" argument for getCallInfo.
it seems that JIT mostly access hClass directly from resolveToken for methods in importer
I would expect that some places want the hClass of the method referenced by the IL and some places want the hClass of the method that the VM resolved the method to. I would not be surprised if there are subtle bugs today like the one you are trying to fix.
|
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
Fixes #93174