Conversation
…ethod which the IL stub is associated with)
…access in IL stub compilation paths
- Restrict generation of IL stubs into R2R binaries where the IL stub may have runtime specific dependencies
- Enable various marshallers - Allow/disallow a few different instructions
- Also tweak logic around corelib ilstub r2r usage so that it actually uses the ilstubs in only the right circumstances
- The cross bitness logic is not correct for IL Stub generation
…o check the exact stub type.
| @@ -1324,19 +1324,44 @@ BOOL ZapSig::EncodeMethod( | |||
| { | |||
| Module * pReferencingModule = pMethod->IsNDirect() ? | |||
There was a problem hiding this comment.
Please document why pReferencingModule is valid to be NULL. Based on existing code this is a core assumption that is no longer value. If there is a way I would strong suggest to remove using NULL as an invariant since this function was written where that was never an issue.
There was a problem hiding this comment.
In particular see previous logic at line 1342.
There was a problem hiding this comment.
The problem is that there isn't a referencing module. Dynamic methods don't really have associated modules in the same way that normal methods do. (In particular, the tokens are not relative to the module, which is what all of the code here is assuming.)
There was a problem hiding this comment.
But a comment is certainly worth it.
| } | ||
| else | ||
| { | ||
| // Dynamic scope case. IL Stubs only |
There was a problem hiding this comment.
Any way we can assert this instead of commenting on it? (i.e. "IL Stubs only" <- can that be asserted?)
| ThrowHR(E_FAIL); | ||
| } | ||
|
|
||
| if (pInfoModule == pMethod->GetModule()) |
There was a problem hiding this comment.
Is this checking where the method's metadata is located? This check warrants a comment I think.
* Basic support for precompiled pinvoke stubs * Generate R2R file with multiple references to same IL stub (one per method which the IL stub is associated with) * Not all il stubs are p/invokes. Don't fail when they aren't. * Consistently use IsDynamicScope and GetModule to avoid unsafe memory access in IL stub compilation paths * Enable full p/invoke il stubs when compiling System.Private.Corelib * Disable IL Stub generation in crossgen for ARM32. - The cross bitness logic is not correct for IL Stub generation Commit migrated from dotnet/coreclr@93675fb
IL stub generation for interop takes measurable time at startup, and it is possible to generate some of them in an ahead of time
This change introduces ahead of time R2R compilation of IL stubs
As of this writing IL stubs do not participate in tiering. Need for this will be investigated before checkin