Debugger talk at Compiler Lab
The CLR team recently had a compiler dev Lab on campus in building 20, with a strong focus on dynamic languages.
I gave a talk on the 3rd day about the debugging services in the .NET platform. It was mainly a buffet-style sampling of what the .NET debugging services offer. Targeting your language .NET gives you a great set of debugging services that free you up to worry about more interesting problems.
The contents were roughly:
- A brief overview of the debugging services ("what is ICorDebug?")
- Raise awareness of MDbg as a toy to prototype new debugging ideas with.
- Demo how you can debugging IL (round-tripping, and via direct tool support such as the Mdbg IL extension)
- A demo of debugging Reflection.Emit (including interop-debugging), and workarounds for the lack of LCG debuggability.
- A Just-My-Code (JMC) demo, and that it can be useful to mark various compiler stubs as non-user code. You can add the DebuggerNonUserCode to dynamically emitted code.
- A quick demo with CLR Profiler.
- Various best practices.
- A plug for the ICorDebug/Mdbg forums.
I've attached a zip file of the handout I used and the demos.
FWIW, I was actually hesitant to give the talk because:
- Giving a debugger talk at a compiler lab is a little rough since you're the odd kid on the block. Everybody else is showing their cool language and stuff; and you're not. John Lam kindly helped me refine the agenda and target it for the audience.
- I'm really naive about dynamic languages, so it's easy to feel out of place. (I felt similarly about the AOP presentation I gave) Using C# examples at a dynamic language lab with Python, Ruby, Boo, APL, + other representatives feels wrong.