Fix for bug #53520, Entry point not found (#53772)
authorTomáš Rylek <trylek@microsoft.com>
Sun, 6 Jun 2021 16:41:22 +0000 (18:41 +0200)
committerGitHub <noreply@github.com>
Sun, 6 Jun 2021 16:41:22 +0000 (18:41 +0200)
commit11c9394f4ef4a1fc66f93b334ee4f29164c4ff44
tree0632fbea124e997ef2288f80a3e81124a3094267
parent2e7e66d3be35861e39c2043f8be921622bc05ec8
Fix for bug #53520, Entry point not found (#53772)

Manish investigated this issue and he found out that the problem
is caused by the fact that in the method

Newtonsoft.Json.Utilities.ReflectionUtils.GetFields

Crossgen2 produces a NewObject fixup for the incorrect type

System.Collections.Generic.List`1<System.Type>

instead of the right type

System.Collections.Generic.List`1<System.Reflection.MemberInfo>

This was caused by a bug in the token harvesting logic; at some
point resolveToken was asked to resolve the token 0x0A02BA,

string [System.Runtime/*23000001*/]System.Type/*01000019*/::get_Name() /* 0A0002BA */

As part of the token harvesting logic we looked at the
MethodReference.Parent (01000019) and stored it in the harvesting
table along with the OwningType of the method. The problem is
that the translation of the MemberReference to MethodDesc
resolves the method on a base class,

string [System.Reflection/*23000009*/]System.Reflection.MemberInfo/*01000076*/::get_Name() /* 0A0002B5 */

As a result we were storing the incorrect [token - type] pair
[01000019 - System.Reflection.MemberInfo] into the type token
translation table and that confused the signature encoder because
01000019 is System.Type.

The trivial solution is to separately translate the memberref
parent entity handle to the owning type entity instead than
extracting it from the MethodDesc. I have verified using R2RDump
that I now see the correct NewObject fixup getting generated
in the method.

Thanks

Tomas
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/ModuleTokenResolver.cs