Partager via

ICorDebugFunction is 1:1 with the IL

  • Article

In CLR 1.0, there was a simple invariant between IL code blob, and native code blob.  It was either 1:0 if the code wasn't jitted, or 1:1 if it was. Method tokens (module scope, mdMethodDef) were also 1:1 with the IL blobs. 1:1 is a nice relationship. Each side can just point to the other without needing to enumerate through a collection.  In this case, you could do a clean mapping from (module, mdMethodDef) <--> IL code blob <--> native code blob.

In CLR 2.0, things got more complicated:

  1. Generics allow 1 IL function to be instantiated and jitted arbitrary number of times to native code. For example, void Foo<T>(T t)  may be the IL function, and it may be instantiated as Foo<int>, Foo<string>, Foo<bar>, etc.   So that makes the IL:Native potentially 1:n, n>= 0.
  2. Edit-and-continue (EnC) allows providing new IL method bodies for an existing mdMethodDef. (It's important to use the existing methodDef instead of creating a new one so that other references to the method pick up the new body). Thus you can start out with Foo() version 1, edit and, and then get Foo() version 2. Each version of Foo() has its own IL blob, but the same mdMethodDef.

Generics + EnC are wonderful features, but they break 1:1 relationships.  We wanted to keep the invariant that the tokens (mdMethodDef) stayed 1:1 with the IL, and ICorDebugFunction was 1:1 with the IL.  

Coping with the breaks:

Since EnC generated new IL blobs, that meant it would generate new ICorDebugFunctions, which would be provided to the debugger via new debug events (ICorDebugManagedCallback2::FunctionRemapOpportunity and FunctionRemapComplete).  Hence we added ICorDebugFunction2::GetVersionNumber() so that the debugger could tell which EnC version each function was for.

ICorDebugCode (for native code) stayed 1:1 with the actual native code blobs. Thus the 1:1 relationship between ICorDebugCode (native) and ICorDebugFunction got broken in CLR 2.0. A single ICDFunction could now map to multiple ICDCodes (1:n). It turns out for source-level debugging, the design patterns rarely needed to map from ICorDebugCode back to ICorDebugFunction, so that was a pretty reasonable place to put the break.

Comments

  • Anonymous
    September 29, 2007
    PingBack from http://www.artofbam.com/wordpress/?p=3955

  • Anonymous
    October 01, 2007
    It's also important to note that the ENC method versions are slightly counter-intuitive.  The invariant is that every method with the same version number was provided in the same call to ICorDebugModule2::ApplyChanges. This means a method can have version 1 & 3 with no version 2.  The 'version' captures how many previous changes were made to the assembly rather than how distinct instances of a method exist.