ICsharpCode.Decompiler integration into VS Debugger · Issue #1901 · icsharpcode/ILSpy (original) (raw)

I am one of the principal developers on the Visual Studio Debugger and the original developer of several of Visual Studio's core debugging scenarios. The ilspy decompiler is a very impressive piece of technology.

We (Visual Studio) are preparing to release a new feature where the ilspy decompiler is fully integrated into the debugger. This will allow users to produce symbols and source while debugging even in cases where modules only exist in memory (such as dump files that contain module memory) or when a user realizes after starting a debug session that decompilation is required.

We are running into some limitations with the symbol sequence point generation. I have been prototyping fixes for these issues, and I would like to start a conversation around them.

  1. Sequence points seem to be getting emitted at locations where the ilstack is not empty. Anytime this happens, the debugger will be incapable of performing evaluations and many times breakpoints will fail to bind. The CLR will consider the current execution location within a can't stop region. Even in release builds, our compilers still often try to empty the il stack across statement boundaries. Note that this is even happening when decompiling debug builds with nop based sequence points in the il.
  2. Sequence points are missing at opening and closing braces. from some other issues, I believe this has been discussed but was determined to be low priority. However, with the VS integration, this breaks several scenarios such as stepping in to a method with symbols, and then invoking the decompiler. As an example, since C# compilers emit sequence points at the opening braces, the debugger with symbols (but without source) will stop on the opening brace of a function during a stepin. If, after stepping in, the user performs decompilation to produce source, the debugger will complain that the current instruction pointer has no source info since the sequence points emitted by the decompiler will not contain this location.

I hope you are as excited about this scenario as we are on the VS Debugger. Fully integrated decompilation will make my own day-to-day workflow much easier.