Lua的debug hook功能探究与改造--上篇 . http://blog.csdn.net/soloist/article/details/1458743

 

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 + y
end

monitor.register(sum)

sum(4,5)
  

它运行后的输出是： 
sum->function: 003D9658 , `call' event
local variables are:
----------------------
x       4
y       5
(*temporary)    nil
(*temporary)    table: 003DA688

sum->function: 003D9658 , `return' event
local variables are:
----------------------
x       4
y       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函数栈框架
     |      .       |      |
     |--------------|<-----|
     |              |
     |--------------|<--栈顶
 

函数return时所有返回值(是的，Lua可以return多个返回值)将依次保存在栈框架上，并且栈顶也跟着调整指向到最后一个返回值 所在单元的下一个位置。如果没有返回值，栈顶将被设为指向栈框架的R(0)位置(相当于清空栈框架)。我们的sum函数返回时R(1) 位置的y变量已被改为88，而R(3)则容纳了返回值92。注意由于每次调hook函数之前都要先到hooktable里查找，所以hooktable 总会遗留在被监控函数栈框架的顶部。此时的布局是： 
     |      .       |      |        
     |      .       |   更上层函数的栈框架
     |      .       |      |
     |--------------|<-----|
     |    R(0)=4    |      |
 x-->|--------------|      |
     |   R(1)=88    |    sum栈框架
 y-->|--------------|      |
     |   R(2)=92    |      |
     |--------------|      |
     |R(3)=hooktable|      |
     |--------------|<-----|
     |      .       |      |
     |      .       |  hook函数栈框架
     |      .       |      |
     |--------------|<-----|
     |              |
     |--------------|<--栈顶
 

搞清楚了栈框架的概念后来看看这段代码: 
require("monitor_v1")

function null()
end

monitor.register(null)

null()
   

运行输出是： 
null->function: 003D9658 , `call' event
local variables are:
----------------------
(*temporary)    nil
(*temporary)    nil
(*temporary)    table: 003DBEE8

null->function: 003D9658 , `return' event
local variables are:
----------------------
(*temporary)    table: 003DBEE8
   

null是个空空如也的函数，它的执行不需要任何栈单元，maxstacksize等于0，所以call null时栈框架上应该只有一个对应 hooktable的`(*temporary)'变量。但是不知道出于什么原因，Lua 5.1.1源码的lparse.c文件的346行有这么一句: 
      f->maxstacksize = 2;  /* registers 0/1 are always valid */
   

也就是说任何函数都会给它分配至少2单元大小的栈框架。这就不难解释null的call事件发生时hooktable前的2个古怪的nil 变量了。又因为函数返回前栈顶已经调整了，所以return时的打印信息只会有一个hooktable。

嗯，到目前为止，是不是觉得一切都很简单？那让我们来看看另外一个例子： 
require("monitor_v1")

function inner(m)
    m = m + 7
    return m * 10
end

function foo(a,b)
    b = b + 10
    return inner(a + b)
end

monitor.register(foo)

foo(7,8)
   

它的运行结果是： 
foo->function: 003D96F0 , `call' event
local variables are:
----------------------
a       7
b       8
(*temporary)    nil
(*temporary)    nil
(*temporary)    table: 003DA6B0
   

咦，这是怎么回事？为什么foo进入调用后就不再返回了？是不是程序出错了？如果程序出错那么解释器应该会异常退出并报告错误 信息，所以从解释器的表现来看foo运行应该一切正常。那么现在就只剩下两种可能：要么是foo的返回事件没有被捕获，要么 就是它根本没有被触发。实际上，问题的真正原因是后者，要搞清楚它先得来熟悉一下尾调用(tail call)的概念。如果某个 return语句的返回值列表只有一项，并且这一项是一个函数调用的话，那么该函数调用称为一个尾调用，Lua虚拟机 有一条专门的叫TAILCALL的指令对这种调用做优化处理。以5.1.1的实现来说，它的具体行为是：在准备尾调用时，虚拟机先象 对待普通调用那样从栈顶开始为被调函数分配一个新的框架，同时调用栈也随之增长并初始化相应数据；接着虚拟机会把栈顶的这些 被调函数的信息(包括栈框架内容和调用栈中的内容)拷贝到调用者的对应位置上，然后数据栈和调用栈都收缩(shrink)一层，最后 再开始执行被尾调用者的函数体。很明显，被尾调用的函数复用了调用者在数据栈和调用栈上的空间，这相当于用被调函数替换了 栈顶的调用者，而调用者则从调用链上彻底消失了，所以系统没有办法再触发调用者的返回事件。下面我们看看实际的情况是否如此， 把上例程序改为： 
require("monitor_v1")

function inner(m)
    m = m + 7
    return m * 10
end

function foo(a,b)
    b = b + 10
    return inner(a + b)
end
-- 对inner也进行监控
monitor.register(inner)
monitor.register(foo)

foo(7,8)
   

它的输出是： 
foo->function: 003D9668 , `call' event
local variables are:
----------------------
a       7
b       8
(*temporary)    nil
(*temporary)    nil
(*temporary)    table: 003DA688

inner->function: 003DA8B0 , `call' event
local variables are:
----------------------
m       25
(*temporary)    nil
(*temporary)    table: 003DA688

anonymous function: 003DA8B0 , `return' event
local variables are:
----------------------
m       32
(*temporary)    320
(*temporary)    table: 003DA688

foo->function: 003DA8B0 , `tail return' event
local variables are:
----------------------
m       32
(*temporary)    320
(*temporary)    table: 003DA688
   

由于尾调用的特殊性，所以被尾调用的函数在返回时触发的事件也有点特殊：不是return而是tail return(奇怪的是，系统却 没有提供与之对应的tail call)。Lua还保证在一个函数的完整执行过程中call事件的总数和return事件加tail return事件 的总数是相等的，这姑且称为事件恒等式吧。从上面的输出信息可以看出，最后一条我们收到的不是foo的return事件，而是为了 维持事件恒等式成立的inner函数的tail return事件(不要被它包含的那个`foo'名字所迷惑，你只要比较函数对象的值就知道 那时的函数是inner，至于Lua怎么巧妙地取得foo这个名字作者将另行撰文分析)，输出的框架信息也是inner函数的。其实只要 存在尾调用，那么函数返回时的栈框架内容将取决于由该函数引发的尾调用链(被尾调用的函数还能尾调用其它函数)的末端函数。 读者或许会问，还有没有办法在foo函数的出口处得到它本身的局部变量信息呢？当然有！请注意，call事件引发的hook函数调用 是在刚刚为被调函数分配并初始化好栈框架之后进行的，也就是说如果调用为尾调用的话，那么此时调用者函数的信息还留在栈上， 只要我们把它保存下来然后待真正返回时(可以利用事件恒等式判断调用者是否返回)再输出就可以了。具体的做法可以参考 monitor_v2.lua。现在只要将 示例程序中的 
require("monitor_v1")
   

改成 
require("monitor_v2")
   

同时删掉对inner的监控(免得信息太多)，就会得到正确的结果： 
foo->function: 003D96F0 , `call' event
local variables are:
----------------------
a       7
b       8
(*temporary)    nil
(*temporary)    nil
(*temporary)    table: 003DA688

foo->function: 003D9658 , `tail return' event
local variables are:
----------------------
a       7
b       18
   

读者一定发现了这次输出的信息少了返回值部分，要解决这个问题需要更深入的挖掘，作者将在本文的下篇中给出详细的解释。