在上一节中简单介绍了 clr 调试器的框架结构，其中提到 clr 调试环境同时支持 native 和 managed 两种模式的调试事件。这一节将从整体上对调试事件做一个概括性的介绍。
首先看看 clr 通过 icordebugmanagedcallback 回调接口提供的 managed 调试事件。这部分的调试事件可以大致分为被动调试事件和主动调试事件：前者由 clr 在调试程序时自动引发被动调试事件，如创建一个新的线程；后者由调试器通过 clr 的其他调试接口，控制 clr 调试环境完成某种调试任务，并在适当的时候引发主动调试事件，如断点和表达式计算。
就被动调试事件来说，基本上对应于 clr 载入运行程序的若干个步骤
首先是动态环境的建立，分为进程、appdomain和线程三级，并分别有对应的建立和退出调试事件：
以下为引用：
interface icordebugmanagedcallback : iunknown
{
//...
hresult createprocess([in] icordebugprocess *pprocess);
hresult exitprocess([in] icordebugprocess *pprocess);
hresult createappdomain([in] icordebugprocess *pprocess,
[in] icordebugappdomain *pappdomain);
hresult exitappdomain([in] icordebugprocess *pprocess,
[in] icordebugappdomain *pappdomain);
hresult createthread([in] icordebugappdomain *pappdomain,
[in] icordebugthread *thread);
hresult exitthread([in] icordebugappdomain *pappdomain,
[in] icordebugthread *thread);
hresult namechange([in] icordebugappdomain *pappdomain,
[in] icordebugthread *pthread);
//...
};
在 clr 的实现上，实际上是存在有物理上的 native thread 和逻辑上的 managed thread 两个概念的。进程和 native thread 对应着操作系统提供的相关概念，而 appdomain 和 managed thread 则对应着 clr 内部的相关抽象。上面的线程相关调试事件，实际上是 native thread 第一次以 managed thread 身份执行 managed code 的时候被引发的。更完整的控制需要借助后面要提及的 native thread 的调试事件。
此外 appdomain 和 managed thread 在创建并开始运行后，都会根据情况改名，并调用 namechange 调试事件，让调试器有机会更新界面显示上的相关信息。
其次是静态 metadata 的载入和解析工作，也分为assembly, module和class三级，并分别有对应的建立和退出调试事件：
以下为引用：
interface icordebugmanagedcallback : iunknown
{
//...
hresult loadassembly([in] icordebugappdomain *pappdomain,
[in] icordebugassembly *passembly);
hresult unloadassembly([in] icordebugappdomain *pappdomain,
[in] icordebugassembly *passembly);
hresult loadmodule([in] icordebugappdomain *pappdomain,
[in] icordebugmodule *pmodule);
hresult unloadmodule([in] icordebugappdomain *pappdomain,
[in] icordebugmodule *pmodule);
hresult loadclass([in] icordebugappdomain *pappdomain,
[in] icordebugclass *c);
hresult unloadclass([in] icordebugappdomain *pappdomain,
[in] icordebugclass *c);
//...
};
在 clr 中，assembly 很大程度上是一个逻辑上的聚合体，真正落实到实现上的更多的是其 module。一个 assembly 在载入时，可以只是保护相关 manifest 和 metadata，真正的代码和数据完全可以存放在不同地点的多个 module 中。因此，在 managed 调试事件中，明确分离了 assembly 和 module 的生命周期。
然后就是对 il 代码中特殊指令和功能的支持用调试事件：
以下为引用：
interface icordebugmanagedcallback : iunknown
{
//...
hresult break([in] icordebugappdomain *pappdomain,
[in] icordebugthread *thread);
hresult exception([in] icordebugappdomain *pappdomain,
[in] icordebugthread *pthread,
[in] bool unhandled);
hresult debuggererror([in] icordebugprocess *pprocess,
[in] hresult errorhr,
[in] dword errorcode);
hresult logmessage([in] icordebugappdomain *pappdomain,
[in] icordebugthread *pthread,
[in] long llevel,
[in] wchar *plogswitchname,
[in] wchar *pmessage);
hresult logswitch([in] icordebugappdomain *pappdomain,
[in] icordebugthread *pthread,
[in] long llevel,
[in] ulong ulreason,
[in] wchar *plogswitchname,
[in] wchar *pparentname);
hresult controlctrap([in] icordebugprocess *pprocess);
hresult updatemodulesymbols([in] icordebugappdomain *pappdomain,
[in] icordebugmodule *pmodule,
[in] istream *psymbolstream);
//...
};
break 事件在执行 il 指令 break 时被引发，可被用于实现特殊的断点等功能；
exception 事件在代码抛出异常时，以及异常未被处理时被引发，类似于 win32 debug api 中的异常事件。后面介绍调试器中对异常的处理方法时再详细介绍；
debuggererror 事件则是在调试系统处理 win32 调试事件发生错误时被引发；
logmessage 和 logswitch 事件分别用于处理内部类 system.diagnostics.log 的相关功能，类似于 win32 api 下 outputdebugstring 函数的功能，等有机会再单独写篇文章介绍相关内容；
controlctrap 事件响应用户使用 ctrl+c 热键直接中断程序，等同于 win32 api 下 setconsolectrlhandler 函数的功能；
updatemodulesymbols 事件在系统更新某个模块调试符号库的时候被引发，使调试器有机会同步状态。
最后还省下几个主动调试事件，在调试器调用 clr 调试接口相关功能被完成或异常时引发：
以下为引用：
interface icordebugmanagedcallback : iunknown
{
//...
hresult breakpoint([in] icordebugappdomain *pappdomain,
[in] icordebugthread *pthread,
[in] icordebugbreakpoint *pbreakpoint);
hresult breakpointseterror([in] icordebugappdomain *pappdomain,
[in] icordebugthread *pthread,
[in] icordebugbreakpoint *pbreakpoint,
[in] dword dwerror);
hresult stepcomplete([in] icordebugappdomain *pappdomain,
[in] icordebugthread *pthread,
[in] icordebugstepper *pstepper,
[in] cordebugstepreason reason);
hresult evalcomplete([in] icordebugappdomain *pappdomain,
[in] icordebugthread *pthread,
[in] icordebugeval *peval);
hresult evalexception([in] icordebugappdomain *pappdomain,
[in] icordebugthread *pthread,
[in] icordebugeval *peval);
hresult editandcontinueremap([in] icordebugappdomain *pappdomain,
[in] icordebugthread *pthread,
[in] icordebugfunction *pfunction,
[in] bool faccurate);
//...
};
breakpoint 和 breakpointseterror 在断点被触发或设置断点失败时被调用，下一节介绍断点的实现时再详细讨论；
stepcomplete 则在调试环境因为某种原因完成了一次代码步进(step)时被调用，以后介绍单步跟踪等功能实现时再详细讨论；
evalcomplete 和 evalexception 在表达式求值完成或失败时被调用，以后介绍调试环境当前信息获取时再详细讨论；
editandcontinueremap 则用于实现调试时代码编辑功能，暂不涉及。
下面是一个比较直观的实例，显示一个简单的 clr 调试环境在运行一个普通 clr 程序除非相关调试事件的顺序
以下为引用：
managedeventhandler.createprocess(3636)
managedeventhandler.createappdomain(defaultdomain @ 3636)
managedeventhandler.loadassembly(e:windowsmicrosoft.net rameworkv1.1.4322mscorlib.dll @ defaultdomain)
managedeventhandler.loadmodule(e:windowsmicrosoft.net rameworkv1.1.4322mscorlib.dll @ defaultdomain)
managedeventhandler.namechange(appdomain=cordbg)
managedeventhandler.createthread(3944 @ cordbg)
managedeventhandler.loadassembly(f:studydotnetdebuggercordbgindebugcordbg.exe @ cordbg)
managedeventhandler.loadmodule(f:studydotnetdebuggercordbgindebugcordbg.exe @ cordbg)
managedeventhandler.namechange(appdomain=cordbg.exe)
managedeventhandler.loadassembly(e:windowsassemblygacsystem.0.5000.0__b77a5c561934e089system.dll @ cordbg.exe)
managedeventhandler.loadmodule(e:windowsassemblygacsystem.0.5000.0__b77a5c561934e089system.dll @ cordbg.exe)
managedeventhandler.createthread(2964 @ cordbg.exe)
managedeventhandler.unloadmodule(f:studydotnetdebuggercordbgindebugcordbg.exe @ cordbg.exe)
managedeventhandler.unloadassembly(f:studydotnetdebuggercordbgindebugcordbg.exe @ cordbg.exe)
managedeventhandler.unloadmodule(e:windowsassemblygacsystem.0.5000.0__b77a5c561934e089system.dll @ cordbg.exe)
managedeventhandler.unloadassembly(e:windowsassemblygacsystem.0.5000.0__b77a5c561934e089system.dll @ cordbg.exe)
managedeventhandler.unloadmodule(e:windowsmicrosoft.net rameworkv1.1.4322mscorlib.dll @ cordbg.exe)
managedeventhandler.unloadassembly(e:windowsmicrosoft.net rameworkv1.1.4322mscorlib.dll @ cordbg.exe)
managedeventhandler.exitappdomain(cordbg.exe @ 3636)
managedeventhandler.exitthread(3944 @ cordbg.exe)
managedeventhandler.exitprocess(3636)
可以看到 clr 首先构造进程和 appdomain；然后将系统执行所需的 mscorlib.dll 载入；接着将要执行的 assembly 和缺省 module 载入；并分析其外部应用(system.dll)，载入之；建立一个新的 managed thread 执行之；最后卸载相关 module 和 assembly，并退出环境。
在打印调试事件信息时值得注意的是很多调试接口都提供了类似的函数从 unmanaged 环境中获取字符串或整数，如
以下为引用：
interface icordebugappdomain : icordebugcontroller
{
hresult getname([in] ulong32 cchname,
[out] ulong32 *pcchname,
[out, size_is(cchname),
length_is(*pcchname)] wchar szname[]);
};
interface icordebugassembly : iunknown
{
hresult getname([in] ulong32 cchname,
[out] ulong32 *pcchname,
[out, size_is(cchname),
length_is(*pcchname)] wchar szname[]);
};
因此在实现上可以将之抽象为一个 delegate，以便共享基于尝试策略的数据获取算法，如
以下为引用：
public class corobject
{
protected delegate void getstrfunc(uint cchname, out uint pcchname, intptr szname);
protected string getstring(getstrfunc func, uint bufsize)
{
uint size = bufsize;
intptr szname = marshal.allochglobal((int)size);
func(size, out size, szname);
if(size > bufsize)
{
szname = marshal.reallochglobal(szname, new intptr(size));
func(size, out size, szname);
}
string name = marshal.ptrtostringuni(szname, (int)size-1);
marshal.freehglobal(szname);
return name;
}
protected string getstring(getstrfunc func)
{
return getstring(func, 256);
}
}
这里使用 marshal 对 native 内存的直接操作，避免编写 unsafe 代码。使用的时候可以很简单地使用
以下为引用：
public class corassembly : corobject
{
private icordebugassembly _asm;
public corassembly(icordebugassembly asm)
{
_asm = asm;
}
public string name
{
get
{
return getstring(new getstrfunc(_asm.getname));
}
}
}
等到 clr 2.0 支持泛型编程后，实现将更加方便。 :p
这一小节，从整体上大致分析了 managed 调试事件的分类和相关功能。具体的使用将在以后的文章中结合实际情况有针对性的介绍。至于 win32 api 调试事件，介绍的资料就比较多了，这里就不在罗嗦，有兴趣进一步研究的朋友可以参考我以前的一个系列文章。
win32 调试接口设计与实现浅析 [2] 调试事件
下一节将介绍 clr 调试接口中断点如何实现和使用。
to be continue...
新闻热点
疑难解答
