Share via

Debugger talk at Compiler Lab

  • Article

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:

  1. A brief overview of the debugging services ("what is ICorDebug?")
  2. Raise awareness of MDbg as a toy to prototype new debugging ideas with.
  3. Demo how you can debugging IL (round-tripping, and via direct tool support such as the Mdbg IL extension)
  4. A demo of debugging Reflection.Emit (including interop-debugging), and workarounds for the lack of LCG debuggability.
  5. 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.
  6. A quick demo with CLR Profiler.
  7. Various best practices.
  8. 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.

 

DevLab_MikeStall_May23_2007.zip

Comments

  • Anonymous
    May 24, 2007
    PingBack from http://mdavey.wordpress.com/2007/05/25/pdc-2007-nothing-to-say/

  • Anonymous
    May 24, 2007
    Hi Mike, It looks like the zip file is corrupt. I can't open it with with Explorer or WinRAR. Are there any plans to support LCG debugging in Orcas? It would be a shame if none of new new DLR based dynamic languages were debuggable! I think I'm correct in saying the DLR is based on LCG. Thanks, Jamie.

  • Anonymous
    May 25, 2007
    Speaking of LCG debugging, are there plans for making it better? e.g., supporting it? :) With the new push for language support built on top of LCG, I was hoping we'd hear more about debugging. Any news?

  • Anonymous
    May 25, 2007
    Unfortunately, we don't have improved LCG debugging support in Orcas. We're working on a good solution a the post-orcas release, although I realize that's little consolence for now. My talk listed some workarounds here. The biggest one is that your code generator can reasonably switch between LCG + Ref.Emit, so have your code generator target Ref.Emit if you want source level debugging. This could be tied to a language's /debug switch. I believe DLR provides both LCG + Ref.Emit support.   p.s.: I double checked the Zip file and it was working. I created it with Winzip. I'll check around here.

  • Anonymous
    May 27, 2007
    I mentioned in the recent dev lab that you can debug at the IL level . I demoed two ways to do this,

  • Anonymous
    May 27, 2007
    Good to hear there's some thought going in to it - I'm guessing you'll post some news about that whenever any information can be made public :) I love reading your posts, even though my specific scenario is rather unorthodox and, by that virtue, unsupported (I'm doing dynamic translation from machine code to IL - which, before someone says anything, works surprisingly well). Learning more about the way the CLR and the debugger works helps me architect my things better. Keep up the amazing work! Now if only there were a nice way to see what happens in managed/native transitions...