Lua5.1提供了较为完善的debug库函数，其中的sethook可以让用户自己设置hook函数来监控程序的某些运行行为，这包括：调用 函数，从函数返回和将要运行新的一行代码，每当这些事件(event)发生时hook函数都会被调用。读者可以试试 monitor_v1.lua， 它是debug hook功能的一个简单应用。require导入该文件后便得到一个名为monitor的扩展库，里面只有一个register函数， 原型为：monitor.register([thread,] func)。调用它后系统便能够监控func函数在thread线程(如果没有指定就是指 调用monitor.register函数时所在的当前线程)中的调用和返回事件：每当事件发生时就打印受监控函数的所有局部变量的名字和 值。请看这段程序： require("monitor_v1")
function sum(x,y) y = 88 return x + yend
monitor.register(sum)
sum(4,5)
它运行后的输出是： sum->function: 003D9658 , `call’ eventlocal variables are:———————-x 4y 5(*temporary) nil(*temporary) table: 003DA688
sum->function: 003D9658 , `return’ eventlocal variables are:———————-x 4y 88(*temporary) 92(*temporary) table: 003DA688
有关x、y的信息很容易理解：它们是传入的实参，在入口处分别为4和5，在出口处则为4和88(y的值在函数体内被更改)。但是 另外两个名为`(*temporary)’的东西是什么呢？为了解释这个问题，先让我们来多了解一点Lua虚拟机的秘密。
同大多数语言一样，Lua也用栈来实现各种过程调用。栈分为调用栈(call stack)和数据栈(data stack)，虚拟机会为每一个被 调用的函数在数据栈上分配一块属于它们自己的连续区域以便存放参数、自定义的局部变量、临时变量和返回值，这就是函数的 栈框架(stack frame)。调用栈的每一层保存的是与该层对应的函数的执行信息(包括函数的元数据、栈框架的起始和结束位置、 子函数调用的返回地址等)，调用栈与数据栈的精确配合是程序正确运行的基本前提。Lua5.1的官方实现用了一个容易让人迷惑的 名字–寄存器(register)来指代栈框架上的存储单元：从框架的基址(base)开始，依次是0号、1号、2号…..寄存器。由于 寄存器就是框架上的存储单元，所以调用栈上不同层的函数的同一序号寄存器指代的并不是同一个栈单元，这点务必弄清。为了方便， 接下来的行文将用栈特指数据栈，用R(X)表示序号为X的寄存器或寄存器的内容，读者根据上下文应该很容易判断它的具体指代。 一个Lua函数可以有多条执行路径，这导致一个函数在每次被调用时使用的栈框架尺寸有可能发生变化，但其中最大的栈框架的大小 完全能够在编译期确定，并且由于该值对将来程序的运行很有帮助，所以每一个编译后的Lua函数都包含了这条信息，官方实现把它 称为maxstacksize。在准备函数调用时虚拟机会根据它的maxstacksize预先分配相应大小的栈框架，这样既能保证这个栈框架 够用(因为按最大需要来分配)，又能免去之后动态调整之累。局部变量的信息是通过debug.getlocal([thread,] level, Y) 取得的。它返回thread线程(如不指定便是当前线程)的调用栈上第level层函数的第Y个局部变量的名字和值。由于Y是从1开始 编号的，所以只要level合法且R(Y-1)位于相应函数的栈框架内，函数就一定返回R(Y-1)对应的名字和值。按照Lua5.1参考手册 的解释，当栈单元保存的是一个具名局部变量(即函数参数和定义在函数体内的local变量)那它对应的名字便是该局部变量的名字， 否则它就是一个内部变量(即循环变量、临时变量和C function的local变量)，名字将以左括号`(‘开头。
回到我们写的sum函数，它的2个参数需要占用2个栈单元，再加上return语句返回的那个表达式需要占一个单元，，所以sum函数需要 的最大栈框架尺寸是3。请读者注意，我们这样估测虚拟机指令的内部信息只是为了说明例子中的问题，人工方法既不可靠也无必要。 如果真想一窥编译后代码的究竟，可以使用一个出色的工具–ChunkSpy，它能方便地反汇编Lua虚拟机的字节码并以一种美观的 方式显示出来，目前已有针对Lua5.0和5.1的版本，主页在 这里。 当sum刚刚开始进入调用还未触发hook函数时，它的栈框架的布局应该是这样的(其中栈顶指的是栈的下一个可用单元)： | . | | . | 更上层函数的栈框架 | . | | |——–|<—–| | R(0)=4 | |x–>|——–| | | R(1)=5 | sum栈框架y–>|——–| | |R(2)=nil| | |——–|<—–| | | |——–|<—栈顶
R(0)和R(1)分别是具名局部变量x和y，R(2)仅是一个预分配单元(它们都被初始化为nil)，所以用getlocal得到的名字就是 `(*temporary)’。现在又有问题了，按照上面的分析应该只有一个内部变量，可为什么后面还会多出一个，而且值为table？其实 我们通过debug.sethook设置的hook函数是由虚拟机以对应线程为key保存在一张名为hooktable的表中，而hooktable则是以 一个light userdata(它的值就是ldblib.c 203行定义的static char变量KEY_HOOK的地址)为key保存在registry表中。 要想找到hook函数需要用lua C API中的压栈函数先把hooktable和线程对象压栈(这会引起栈的增长)，再用lua_rawget取得 hook函数，然后压入合适的参数并用lua_call调用它。由于lua_rawget不会把表弹出栈，所以hooktable仍然留在sum函数的 栈框架顶部。需要提醒的是，hooktable是一个动态分配的对象，所以每次运行程序它输出的地址都可能不同。进入到hook函数后 相应栈布局是： | . | | | . | 更上层函数的栈框架 | . | | |————–|<—–| | R(0)=4 | |x–>|————–| | | R(1)=5 | sum栈框架y–>|————–| | | R(2)=nil | | |————–| | |R(3)=hooktable| | |————–|<—–| | . | | | . | hook函数栈框架 | . | | |————–|<—–| | | |————–|<–栈顶
世界会向那些有目标和远见的人让路(冯两努–香港着名推销商
