Iron Curt : Guts

Viewing Emitted IL

curth — Wed, 13 Aug 2008 06:28:28 GMT

Let's say you're working on a project such as IronPython or IronRuby that makes use of Reflection.Emit to generate code at runtime. You're probably used to seeing a stack trace in Visual Studio that looks something like this:

Visual Studio will do its best to prevent you from viewing any part of that [Lightweight Function]. It won't let you trace into those methods, even while viewing from assembly language. If you're feeling clever, you can use the registers view and the and memory view to identify the return address on the stack, but there's no way of knowing for sure whether or not the caller is actual code or just a thunk of some kind.

But it turns out that there's another way of doing this that's fairly straightforward.

Enter SandWindbag

The managed debugger operates at a fairly high level of abstraction (as far as debuggers go). So when the going gets tough, the tough resort to windbg.exe (or its command-line cousin cdb.exe). These are part of the Debugging Tools for Windows, which can be downloaded from http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx.

Here's what you need to do.

1. If you're not viewing it in Visual Studio already, bring up the Debug Location toolbar, which looks like this:

This will tell us the name and id of the process and thread that we need to connect to from windbg.

2. If you haven't already, start windbg. From the File menu, select Attach to a Process -- or hit F6.

Here's the key part. When you select the process for connecting, you want to specify that it's a noninvasive attach:

In Windows, only a single process can connect to any given other process as the debugger. Visual Studio is already the registered debugger for this instance of IronPython, so windbg cannot establish the same relationship with it. What "Noninvasive" debugging does is to use SuspendThread to suspend all the threads in the target process and then use ReadProcessMemory to access its internals. At that point, it's not unlike debugging a core dump; you have the entire memory image to look at, but you can't actually set breakpoints or execute any code inside that process.

There's plenty of information about noninvasive debugging at various locations on the net.

For our needs -- looking at the MSIL and the native machine code for methods generated through Reflection.Emit -- this turns out to be good enough.

3. Now we'll want to load the SOS Debugging Extension. This actually ships with the .NET runtime now, so there should be nothing for you to load. Unfortunately, the ".loadby" windbg command doesn't seem to work when we do a noninvasive connect, so you'll have to type a full path in the command to load the extension. With a default installation of Windows, this will probably be

.load C:\Windows\Microsoft.NET\Framework\v2.0.50727\SOS.dll (for a 32-bit process), and
.load C:\Windows\Microsoft.NET\Framework64\v2.0.50727\SOS.dll (for a 64-bit process).

4. Let's make sure that we're looking at the right thread. You can get a list of threads by using the "~" command, or you can choose "Processes and Threads" from the View menu. The thread identifiers here are expressed in hexadecimal, so you'll need to do a quick conversion from the "1440" in Visual Studio to 5a0. Here's the output from the "~" command.

0:000> ~
.  0  Id: 1c04.15f8 Suspend: 1 Teb: 7ffdf000 Unfrozen
   1  Id: 1c04.11e8 Suspend: 1 Teb: 7ffde000 Unfrozen
   2  Id: 1c04.16cc Suspend: 1 Teb: 7ffdd000 Unfrozen
   3  Id: 1c04.d08 Suspend: 1 Teb: 7ffdc000 Unfrozen
   4  Id: 1c04.153c Suspend: 1 Teb: 7ffda000 Unfrozen
   5  Id: 1c04.1478 Suspend: 1 Teb: 7ffd7000 Unfrozen
   6  Id: 1c04.d14 Suspend: 1 Teb: 7ffd9000 Unfrozen
   7  Id: 1c04.102c Suspend: 1 Teb: 7ffd6000 Unfrozen
   8  Id: 1c04.ac0 Suspend: 1 Teb: 7ffd5000 Unfrozen
   9  Id: 1c04.1118 Suspend: 1 Teb: 7ffd4000 Unfrozen
  10  Id: 1c04.5a0 Suspend: 1 Teb: 7ffd3000 Unfrozen
  11  Id: 1c04.13d8 Suspend: 1 Teb: 7ffd8000 Unfrozen

In this list, thread 10 matches the one where we hit the breakpoint in Visual Studio -- so we can switch to this thread from thread 0 by executing "~10 s". Alternatively, if you were viewing the "Processes and Threads" window, you could just double-click on the thread in question.

5. Now we're ready to look at the stack. Execute the command "!clrstack". The output should closely resemble the stack trace that you see in Visual Studio -- except now you'll see names for all of those "Lightweight Function" frames. You'll also get the stack pointer and instruction pointer for each frame. The result should look something like this:

0:010> !clrstack
OS Thread Id: 0x66c (10)
ESP       EIP     
0572da10 04f85469 IronPython.Modules.PythonNT.chdir(System.String)
0572da80 04a81b99 DynamicClass._stub_$11##11(System.Runtime.CompilerServices.Closure, System.Scripting.Actions.CallSite, System.Scripting.Runtime.CodeContext, System.Object, System.String)
0572dab8 04a81ab1 DynamicClass._stub_MatchCaller(System.Object, System.Scripting.Actions.CallSite, System.Object[])
0572dae4 047fa24d System.Scripting.Actions.CallSite`1[[System.__Canon, mscorlib]].UpdateAndExecute(System.Object[])
0572dc68 04f60307 System.Scripting.Actions.UpdateDelegates.Update3[[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib]](System.Scripting.Actions.CallSite, System.__Canon, System.__Canon, System.__Canon)
0572dce8 04a81925 DynamicClass.<module>$10##10(System.Runtime.CompilerServices.Closure, System.Scripting.Runtime.Scope, System.Scripting.Runtime.LanguageContext)
0572dd88 04a74ab8 System.Scripting.ScriptCode.InvokeTarget(System.Linq.Expressions.LambdaExpression, System.Scripting.Runtime.Scope)

6. That second-from-top entry looks intriguing. How can we see its code? The first thing we need to do is to get a method descriptor for it, which we can do using the SOS command !ipmd.

0:010> !ip2md 04a81b99
MethodDesc: 047ee580
Method Name: DynamicClass._stub_$11##11(System.Runtime.CompilerServices.Closure, System.Scripting.Actions.CallSite, System.Scripting.Runtime.CodeContext, System.Object, System.String)
Class: 047ee2c0
MethodTable: 047ee324
mdToken: 06000000
Module: 047e6b48
IsJitted: yes
CodeAddr: 04a81b18

With the method descriptor, the !dumpil command will show us the actual MSIL for this method.

0:010> !dumpil 047ee580
This is dynamic IL. Exception info is not reported at this time.
If a token is unresolved, run "!do <addr>" on the addr given
in parenthesis. You can also look at the token table yourself, by
running "!DumpArray 01eb82ec". 
IL_0000: ldarg.3 
IL_0001: ldarg.0 
IL_0002: ldfld 4000002 (01eb7c4c)
IL_0007: ldc.i4.0 
IL_0008: ldelem.ref 
IL_0009: castclass 2000003 "System.WeakReference"
IL_000e: callvirt 6000004 System.WeakReference.get_Target()
IL_0013: ceq 
IL_0015: brfalse IL_0023
IL_001a: ldarg.s VAR OR ARG 4
IL_001c: call 6000005 IronPython.Modules.PythonNT.chdir(System.String)
IL_0021: ldnull 
IL_0022: ret 
IL_0023: ldarg.1 
IL_0024: castclass 2000006 "System.Scripting.Actions.CallSite`1[[System.Scripting.Actions.DynamicSiteTarget`4[[System.Scripting.Runtime.CodeContext, Microsoft.Scripting.Core],[System.Object, mscorlib],[System.String, mscorlib],[System.Object, mscorlib]], Microsoft.Scripting.Core]]"
IL_0029: ldfld 4000007 (01eb8120)
IL_002e: ldarg.1 
IL_002f: ldarg.2 
IL_0030: ldarg.3 
IL_0031: ldarg.s VAR OR ARG 4
IL_0033: callvirt 6000008 System.Scripting.Actions.DynamicSiteTarget`4[[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib]].Invoke(System.Scripting.Actions.CallSite, System.__Canon, System.__Canon, System.__Canon)
IL_0038: ret 
IL_0039: ldnull 
IL_003a: ret

If you want to see what the associated x86 or x64 machine code looks like, the "CodeAddr" value from the !ip2md command will give you the starting address of the JITted code. You can use this with the windbg "u" command (for "unassemble").

7. Once you're done, be sure to detach windbg from the program you're looking at; it's quite likely that Visual Studio will be hung until you do. That's because it will be waiting to get data back from the debug thread that was injected into the target process -- but windbg has suspended that thread on your behalf. "Detach Debuggee" is a menu choice on the "Debug" menu.

Left as an Exercise to the Reader

One of the interesting things that's possible with cdb.exe -- the command-line version of windbg.exe -- is to control it from a separate program. All of the functionality we used above is accessible through cdb. You can therefore write a program that starts a separate cdb process, piping commands to its standard input and reading -- and parsing -- the results from its standard output. You could even write a GUI that shows the stack of the target process, and when the user clicks on a frame it puts up the MSIL for that frame into one pane and the assembly code into another.

Write it using IronPython.

This... is... Dynamic!

curth — Fri, 01 Aug 2008 02:47:21 GMT

Regarding our need to check-and-rethrow exceptions in IronPython, int19h asks "Shouldn't exception filters do the trick without the need to rethrow explicitly?"

That's a good question. In fact, I had the exact same reaction when I first started looking into this issue. So I changed IronPython's MSIL generation to use filters, and my updated version was able to pass all of our tests.

Later, during my weekly face-to-face meeting with Shri, I described the work I had done and Shri was immediately able to identify a corner case that was now broken.

Results 1 - 10 of about 163 for "vb.net" "jan brady"

Before looking at some sample Python code that causes the problem, it's worth digging a little into filters to learn something about their operation. To do so, I'll need to leave my comfort zone and enter the world of VB.NET -- as C# doesn't have any functionality that maps onto MSIL exception filters.

Consider the following code:

    Function CheckException(ByVal pos As Integer) As Boolean
        System.Console.WriteLine("Filter {0}", pos)
        CheckException = (pos = 0)
    End Function
 
    Sub Test(ByVal i As Integer, ByVal max As Integer)
        Try
            If i < max Then
                Test(i + 1, max)
            Else
                Throw New ApplicationException("Exception Occurred")
            End If
        Catch ex As Exception When CheckException(i)
        Finally
            System.Console.WriteLine("Finally {0}", i)
        End Try
    End Sub
 
    Sub Main()
        Try
            Test(1, 4)
        Catch ex As Exception When CheckException(0)
        End Try
    End Sub

This code is designed so that the exception filter in the Test() method will always return false while the one in Main() will return true. As a side effect of calculating this value, the filter will give us a visual notification that it has run.

The exception handlers form a stack that will be traversed in reverse calling sequence, running the Finally block of each Test() invocation before continuing back up the chain. Our natural expectation is that the filter will be executed just before the Finally, giving us output that looks like this:

Filter 4
Finally 4
Filter 3
Finally 3
Filter 2
Finally 2
Filter 1
Finally 1
Filter 0

But what we get when we run the code is output that actually looks like this:

Filter 4
Filter 3
Filter 2
Filter 1
Filter 0
Finally 4
Finally 3
Finally 2
Finally 1

So what happens instead is that the CLR actually walks the list of exception handlers twice. The first time, it's looking for a catch block that will handle the exception. In the course of doing so, it needs to run any filter methods it encounters in order to identify whether or not that particular catch block is "the one". Only once it finds an exception handler does it go back and run all of the finally and fault blocks between the thrower and the catcher.

You fascinate me; tell me more!

This subtlety matters to us because of the dynamic nature of the Python language. You can't reliably evaluate any expression in the dynamic world until you reach that particular point in the code -- because the meaning of just about anything is subject to change.

Here's the Python code that demonstrates the problem:

x = RuntimeError
def test():
    global x
    try:
        raise x
    finally:
        x = SyntaxError
 
try:
    test()
except x:
    print 'Match'
except:
    print 'Mismatch'

In order for this to work correctly, the exception criteria "except x" at the top level must run after x is reassigned in the finally block of the test() method. But if we use an exception filter to match the thrown exception against x, the filter will run before the value of x is set to SyntaxError and it will incorrectly report that it is the right handler for the job.

And even though this is an edge case, there's nothing that actually distinguishes this code from the more usual example of "except RuntimeError" where we supply the type of the exception. That's because the meaning of the symbol can't be determined until runtime no matter how familiar it may look to human eyes. This is in sharp contrast to a statically typed language, where "catch (ArgumentException)" has to be resolvable to a definite type at build time or it's an error.

This is part of what it means to be dynamic. Take the power and use it wisely.