This PR introduces MethodDesc parsing for .NET Core 3.0+, which can be opt out of by setting the environment variable MONOMOD_RUNTIMEDETOUR_NETCORE30PLUS_OLDFTNPTR to 1.
Quoting myself from the MonoMod Discord server:
I see it as either "keep up with runtime internals by parsing methoddescs" or "keep up with runtime internals on a per platform basis by trying to understand what the JIT emits"
in the past, the runtime was a black box and "fixing" RuntimeMethodHandle.GetFunctionPointer might've been less effort than trying to understand methoddescs
but nowadays precode walking is stable enough on framework, coreclr is open source, yet another platform is on the horizon, and it feels like there are more combinations of stubs and platforms than there are variations of method descriptors to grab pointers from
Reducing the dependency on precode walking should also theoretically help with getting new platforms up and running faster, such as ARM. My current focus is fixing an edge case interaction between RuntimeDetour and coreclr's backpatcher though, discovered by tModLoader modders, where RuntimeDetour's precode walker misinterprets the location of the method desc in the method table as the location of the code and zeroes it out, shortly before the runtime dies on a backpatch attempt.
This PR introduces
MethodDescparsing for .NET Core 3.0+, which can be opt out of by setting the environment variableMONOMOD_RUNTIMEDETOUR_NETCORE30PLUS_OLDFTNPTRto1.Quoting myself from the MonoMod Discord server:
Reducing the dependency on precode walking should also theoretically help with getting new platforms up and running faster, such as ARM. My current focus is fixing an edge case interaction between RuntimeDetour and coreclr's backpatcher though, discovered by tModLoader modders, where RuntimeDetour's precode walker misinterprets the location of the method desc in the method table as the location of the code and zeroes it out, shortly before the runtime dies on a backpatch attempt.