Debugging Support for AOP on 'NET

1
Debugging Support for AOP on .NET

• AOP Workshop
• Nov 14, 2005

2
Goals

• Its a 15 minute presentation, so lets be
  realistic about the goals
• Raise awareness about making AOP debuggable.
• Address some common questions weve been getting
  (such as EnC AOP, and VS extensibility).
• Provide folks with links to further data, so they
  can follow-up afterwards.

3
Overview

• What does AOP debuggability mean to an end-user?
• Whats the technical challenge?
• Debuggability for rewriting-IL.
• Debugger Application vs. Platform.

4
What does AOP debuggability mean?

• We dont really know. We work on debuggers. We
  have no practical experience with AOP and little
  theoretical knowledge ?
• What we do know about AOP is that
• Weaving means rewriting the IL
• The end user needs to be able to comprehend the
  weaved programs behavior, ideally at the
  source-level
• We want to learn from you what core functionality
  we could enable to make it easier for you to
  build best-of-breed AOP tools

5
The Technical Challenge

• Well focus on Rewritten IL at platform level.
• Need to map from Native Code (whats actually
  running) ? IL ? Source (what user understands).
• CLR JIT tracks the Native?IL maps.
• AOP rewrites the IL, so we need updated IL?Source
  maps.
• More issues outside scope of this presentation
• What is the ideal end-user model?
• Will need debugger cooperation for AOP-specific
  semantics.
• May need rewriting concepts that dont exist
  today.

6
The PDB (Managed Code)

• Contains IL?Source mappings for line numbers and
  local variable names.
• Other info (like function names) are in the
  metadata in the executable.
• Does not allow any additional meta information
  like weaved IL
• Public read/write API (corsym.idl), private file
  format.

7
Options for Rewriting IL
8
Dont use EditContinue (EnC) for AOP

• May not be possible because it Requires AOP
  engine to be the debugger.
• Only a debugger can do EnC. Detach is disabled in
  EnC.
• and only 1 debugger can be attached.
• Thus your AOP engine must attach as a debugger to
  do EnC which prevents a real debugger from
  attaching.
• Workarounds
• An extremely extensible debugger.
• Your AOP engine is the debugger.

9
Dont use EnC for AOP (cont)

• (2) Current implementation is poorly suited for
  AOP
• Unbounded memory usage
• Doesnt pitch old methods or symbols
• Not robust interface in face of API errors.
• Very complicated interface. Difficult to get the
  delta IL or pdb blobs.
• Consuming EnC is a very large undertaking.

10
Dont use EnC for AOP (cont)

• (3) Many Technical restrictions to not use EnC
  for weaving
• Only available in V2.0.
• Requires AOP engine to be the debugger.
• Very restrictive edits.
• Can only let you add private methods, fields, and
  change method bodies.
• Cant add new types, custom attributes or public
  members.
• Other restrictions. Wont work w/ profiler, ngen,
  ref-emit. Wont work in attach-scenarios
  (specifically, cant work on code loaded before
  debugger attached). Cant detach.
• Not intended for production apps.
• Entirely scenario driven by VB IDE requirements.
  Eg, expected usage is that you eventually get a
  rude-edit and restart the app.
• Not stress tested like server scenarios are.
• Must be explicitly enabled, and then has
  highly-unoptimized code-gen.

11
Application vs. Platform

• So far, focused on CLR platform issues, thus
  apply to all debuggers.
• Debugger (including VS) are just applications
  that consume the debugging APIs, each has its own
  extensibility model.
• Use ext. model to get an integrated AOP-IDE
  experience (eg, if you want the IDE to grey out
  weaved code).
• For Visual Studio
• Spectrum Macros / Plug-ins (Tool-windows) / VSIP
• Visualizers allow graphical view into data.
• VS extensions are an entire area in themselves.
• http//msdn.microsoft.com/vstudio/extend/default.a
  spx

12
The End

• Contacts
• CLR Debugging (ICorDebug)
• Mike Stall http//blogs.msdn.com/jmstall
• Rick Byers http//blogs.msdn.com/rmbyers
• Jon Langdon jlangdon_at_microsoft.com
• CLR Profiling (ICorProf)
• Jonathan Keljo http//blogs.msdn.com/jkeljo
• David Broman http//blogs.msdn.com/davbr

13
(No Transcript)
14
Bonus Slides
15
Rewriting with CLR Profiling

• Lets you rewrite function body IL
  (SetILFunctionBody), supply translation map IL
  new ? IL old (SetILInstrumentedCodeMap ).
• All done in-place, so no intermediate files.
• Limitations
• Only 1 profiler can attach (may be able to mux
  profilers).
• Only intended for injecting instrumentation.
• Cant add new fields, types, etc.
• Cant attach.
• Only occur at load. Only edit each method once
  (rejit deprecated in V2)
• Final pipeline
• Native new ? IL new JIT maps.
• IL new ? IL old from SetILInstrumentedCodeMap
• IL old ? Source From PDBs.
• Profiling API defined in CorProf.idl.
• Complicated unforgiving interface

16
Feature Requests weve heard

• Allow custom information in the PDBs
• Add some sort of general rewriting concepts to
  debugging API.
• Allow custom attributes to describe a range of
  IL within a method.
• Contact us if there are other requests!