之前搞过一下systemtap（systemtap折腾笔记），可惜很快琐事缠身，没有继续搞下去。最近偷空搞了一下，有点意思。
章大大的思路，是用perl生成systemtap脚本，从/proc/$pid/maps里面扫出liblua.so的地址。然后hook这个地址里，以luaL_*和lua_*开头的lua虚拟机C函数。hook住的函数里，都会有个参数L，这个L表示lua的虚拟机。接下来就是按lua的C代码撸一遍，看看怎么从L的内存结构里，dump出整个lua的运行栈。相当于在systemtap里，重新实现一遍官方的debug.traceback。
换到skynet里实现，有几个不同点。首先，skynet是把lua静态编译进去的，所以无法找到liblua.so。其实这样问题更简单了，不需要扫so的地址，只要hook住skynet里的相关函数，一样可以拿到L的地址。其次，是skynet用的是魔改版的lua，所以proto的位置与官方版有点不同，而且现在用的是lua53了，跟openresty的lua51比还是有差异的。我实现了一版给skynet用的lua-bt，参见skynet_systemtap_set仓库里的mini_lua_bt.stp
做出来的效果就是上图这样。因为没有用户登录，所以只有一个exchange服务在跑。这个服务是用于和平台通讯的，所以会定时处理一些消息。
目前还有点小问题，有时候同一个栈位置会打印两次，还没找到原因。另一个是目前打印的是文件名和行数，没有函数名直观。但是lua的函数其实只是一个指针，可以给这个指针绑定不同的名字，都是同一个函数，而且代码里还有大量的匿名函数，所以不好搞出来函数名。另外，从skynet的结构来说，其实可以找到更接近业务层的点。skynet底层是socket-server，然后用sn-lua跑lua服务，再用lua-skynet.c为lua服务提供skynet的接口。hook住lua-skynet的lcallback，应该就能看到skynet调lua业务的东西了。不过这个还没搞好……
接下来再慢慢补充一下其他类型的脚本。。