云风的 BLOG

每次做完送给人用了两天就扔掉了。这次一时兴起，周末又做了一个。当然每次都会有一些不一样的想法。

这次的版本只开了个头，把构想中的基础架构搭好了。那就是，我认为一个优雅的调试器不应该过多的干涉被调试的实体（比方说你想监控被调试的程序内存使用的情况，和 gc 的工作）。

过去的一些版本都是把调试器代码直接嵌入被调试的虚拟机的，调试器本身和被调试的代码并没有明显的界限。调试过程也会在同一个虚拟机中运行。

我这次想玩点不一样的，让调试器运行在一个独立的虚拟机内，它通过一组接口来观察被调试程序。这样，在这个基础上制作的调试器，可以更放心的添加一些花哨的功能了。比如启动一个图形界面、或是提供一个 web server ，调试者可以通过浏览器来监控内部状态，发送调试指令。

当然最简单的用法是非侵入式的输出 log 。不必在被调试代码中硬加上几句 print 输出 log （这是没有调试工具时，大家最常用的调试方法），而可以把 print 查看内部状态的代码写在独立的调试器模块中。我们可以用编程的方式来编写调试过程，而不局限于一个交互式调试工具提供的有限手段。

我这次设计的调试模块，只提供一个概念：探测点。

你可以在被调试代码中设置探测点，探测点并不是断点，而更像一个观测点。在这个点上，调试器并不会停下来等待调试者的指令，而是运行调试器里的一个函数。（这个函数是运行在独立的虚拟机里的，完全不用担心代码有什么副作用）

你可以在探测点函数中，访问被调试代码在该处的状态，做一些合适的事情。比如把状态输出到 log 文件中，比如根据状态条件来选择做些事情；当然也可以暂停下来，交互式等待调试命令。

探测点可以分为两种，一种是在调试前，硬编码在代码中的，只要运行到那里，就会触发一下探测行为；还有一种是利用 lua 的 Hook 透明添加的。

两种探测点可以混合使用。比如在游戏主循环中预先硬编码进一个探测点，平时不启动调试器，运行到探测点时就自动忽略；当需要的时候，让这个探测点起作用，然后在探测函数中，设置 hook 点，进一步的调试。

初步的代码放在 github 上，这段时间会慢慢完善。不过期待它短期内发展成为一个图形式的漂亮交互调试器可能有点不现实，除非做前端的朋友有兴趣来完善它。（比如增加一个 web server ，直接可以通过浏览器连接到程序里交互调试）

最后说点这个东西的实现中一个有趣的部分：

由于调试器和被调试程序处于两个不同的 VM 中，所以调试器代码并不能直接引用被调试代码环境中的 table 。这里是怎么做到的呢？

我设计了一个 C 结构（封装成 userdata），里面保存了一个无法被直接引用的 lua 对象的引用路径。

比如，从探测点出发，你想获得某个对象的状态，无非只有几个途径。获取某个栈帧的 local 变量、upvalue 、或是从全局表中检索到一个对象等等，如果这个对象是一个 table ，可以进一步的去取 table 里的子域。总之，你总是通过一层层的简洁途径获得最终想观察的变量的。

那么，在调试器中，只需要把这个过程记录下来、而不需要铆定一个特定的对象。这个过程封装成一个 userdata ，它的实际含义和最终对应的对象是一致的。