1# Debugger Engine backend 2 3This directory contains the Dexter backend for the Windows Debugger Engine 4(DbgEng), which powers tools such as WinDbg and CDB. 5 6## Overview 7 8DbgEng is available as a collection of unregistered COM-"like" objects that 9one accesses by calling DebugCreate in DbgEng.dll. The unregistered nature 10means normal COM tooling can't access them; as a result, this backend uses 11ctypes to describe the COM objects and call their methods. 12 13This is obviously not a huge amount of fun; on the other hand, COM has 14maintained ABI compatible interfaces for decades, and nothing is for free. 15 16The dexter backend follows the same formula as others; it creates a process 17and breaks on "main", then steps through the program, observing states and 18stack frames along the way. 19 20## Implementation details 21 22This backend uses a mixture of both APIs for accessing information, and the 23direct command-string interface to DbgEng for performing some actions. We 24have to use the DbgEng stepping interface, or we would effectively be 25building a new debugger, but certain things (like enabling source-line 26stepping) only seem to be possible from the command interface. 27 28Each segment of debugger responsibility has its own COM object: Client, 29Control, Symbols, SymbolGroups, Breakpoint, SystemObjects. In this python 30wrapper, each COM object gets a python object wrapping it. COM methods 31that are relevant to our interests have a python method that wraps the COM 32one and performs data marshalling. Some additional helper methods are added 33to the python objects to extract data. 34 35The majority of the work occurs in setup.py and probe_process.py. The 36former contains routines to launch a process and attach the debugger to 37it, while the latter extracts as much information as possible from a 38stopped process, returning a list of stack frames with associated variable 39information. 40 41## Sharp edges 42 43On process startup, we set a breakpoint on main and then continue running 44to it. This has the potential to never complete -- although of course, 45there's no guarantee that the debuggee will ever do anything anyway. 46 47There doesn't appear to be a way to instruct DbgEng to "step into" a 48function call, thus after reaching main, we scan the module for all 49functions with line numbers in the source directory, and put breakpoints 50on them. An alternative implementation would be putting breakpoints on 51every known line number. 52 53Finally, it's unclear whether arbitrary expressions can be evaluated in 54arbitrary stack frames, although this isn't something that Dexter currently 55supports. 56 57