Writing a .net debugger (part 4) – breakpoints

After the last part the mindbg debugger stops at the application entry point, has module symbols loaded and displays source code that is being executed. Today we will gain some more control over the debugging process by using breakpoints. By the end of this post we will be able to stop the debugger on either a function execution or at any source line.

Setting a breakpoint on a function is quite straightforward – you only need to call CreateBreakpoint method on a ICorDebugFunction instance (that we want to have a stop on) and then activate the newly created breakpoint (with ICorDebugBreakpoint.Activate(1) function). The tricky part is how to find the ICorDebugFunction instance based on a string provided by the user. For this purpose we will write few helper methods that will use ICorMetadataImport interface. Let’s assume that we would like to set a breakpoint on a Test method of TestCmd class in testcmd.exe assembly. We will then use command “set-break mcmdtest.exe!TestCmd.Test”. After splitting the command string we will receive module path, class name and method name. We could easily find a module with a given path (we will iterate through the modules collection – for now it won’t be possible to create a breakpoint on a module that has not been loaded). Having found a module we may try to identify the type which “owns” the method. I really like the way how it is done in mdbg source code so we will copy their idea

Read more: Low Level Design

Posted via email from .NET Info