SystemTap使用技巧【一】

       SystemTap是一个强大的调试工具，确切的说应该是一门调试语言，因为它有自己的语法，也有解析、编译、运行等过程（准确的说有五个阶段），但它主要解决的问题是收集Linux内核或者用户进程的信息，主要目的是调试。我一直以为gdb、kgdb是Linux最强大的调试器，曾经爱不释手，自从发现了SystemTap之后，又有了当初喜欢gdb的那种感觉了，真的是相见恨晚啊。gdb和SystemTap不是竞争关系，而是互补关系，gdb能做的事情SystemTap做不到，比如断点/watch变量等等这些SystemTap都做不到，而SystemTap能做的事情gdb做不到或者非常麻烦才做到，比如很方便查看内核调试栈/嵌入C语言等等gdb就傻眼了。SystemTap真的非常强大，会了这个又觉得自己帅几个百分点了。来看一下几个技巧吧：

1、定位函数位置。

       比较典型的是定位内核系统调用函数在哪个文件上，以往我都是source insight或者grep找，比如要找open系统调用在内核的实现，就这样： 

root@jusse ~/linux-source-3.13.0# grep -nr 'SYSCALL_DEFINE3(open' ./ ./fs/compat.c:1075:COMPAT_SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, mode) ./fs/compat.c:1461:COMPAT_SYSCALL_DEFINE3(open_by_handle_at, int, mountdirfd, ./fs/open.c:1011:SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, mode) ./fs/fhandle.c:254:SYSCALL_DEFINE3(open_by_handle_at, int, mountdirfd,

       Linux比较新的内核定义系统调用都是SYSCALL_DEFINE方式，不像以前可以通过关键字sys_open来找，非常麻烦而且很慢，如果用SystemTap的话一个命令就搞定了：

root@jusse ~/linux-source-3.13.0# stap -l 'kernel.function("sys_open")' kernel.function("SyS_open@/build/buildd/linux-lts-trusty-3.13.0/fs/open.c:1011")

       我们很快知道open系统调用的实现代码就在fs/open.c的第1011行，搜索比grep快，而且很准确。

       同理，我们也可以用来定位用户进程的函数位置：

       比如nginx的文件ngx_shmtx.c里面为了兼容各个操作系统而实现了两个版本的ngx_shmtx_trylock锁操作，用#if (NGX_HAVE_ATOMIC_OPS)、#else、#endif来做条件编译，那怎么知道我们编译出来的是哪个版本呢，用SystemTap的话就很简单了，否则要去grep一下这个宏NGX_HAVE_ATOMIC_OPS有没有定义才知道了，看看SystemTap的例子吧：

root@jusse ~/develop# stap -l 'process("/opt/nginx/sbin/nginx").function("ngx_shmtx_trylock")'    process("/opt/nginx/sbin/nginx").function("ngx_shmtx_trylock@src/core/ngx_shmtx.c:63")

       ngx_shmtx.c第63行就是编译出来的版本。

       另外也可以定位出nginx中所有以ngx_epoll_开头的函数在哪里：

root@jusse ~/work/nginx# stap -l 'process("/opt/nginx/sbin/nginx").function("ngx_epoll_*")' process("/opt/nginx-dso/sbin/nginx").function("ngx_epoll_add_connection@src/event/modules/ngx_epoll_module.c:502") process("/opt/nginx-dso/sbin/nginx").function("ngx_epoll_add_event@src/event/modules/ngx_epoll_module.c:386") process("/opt/nginx-dso/sbin/nginx").function("ngx_epoll_create_conf@src/event/modules/ngx_epoll_module.c:807") process("/opt/nginx-dso/sbin/nginx").function("ngx_epoll_del_connection@src/event/modules/ngx_epoll_module.c:526") process("/opt/nginx-dso/sbin/nginx").function("ngx_epoll_del_event@src/event/modules/ngx_epoll_module.c:444") process("/opt/nginx-dso/sbin/nginx").function("ngx_epoll_done@src/event/modules/ngx_epoll_module.c:348") process("/opt/nginx-dso/sbin/nginx").function("ngx_epoll_init@src/event/modules/ngx_epoll_module.c:295") process("/opt/nginx-dso/sbin/nginx").function("ngx_epoll_init_conf@src/event/modules/ngx_epoll_module.c:824") process("/opt/nginx-dso/sbin/nginx").function("ngx_epoll_process_events@src/event/modules/ngx_epoll_module.c:564")

2、查看实际的函数。

       如果对nginx或者内核代码有点了解的，可能知道很多地方数据结构里面用到了函数指针，这是C语言里面向对象思想的编程方式，非常有用，但对看代码的人来说就不太方便了。最近在csdn的linux bbs里看到这个帖子：http://bbs.csdn.net/topics/390972532，为了满足自己对底层实现的好奇心就深入地研究了一把。问题是这样：我想知道内核里一个进程的进程组组长pid存在task_struct的什么地方，通过ps可以看出进程的pgid一般是自己的pid或者父进程pid：

root@jusse ~# ps -ef -o pid,ppid,pgid,comm Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html PID PPID PGID COMMAND 28400 28399 28400 bash 5637 28400 5637 \_ cc_epoll 5638 5637 5637 \_ cc_epoll 5639 5637 5637 \_ cc_epoll 5640 5637 5637 \_ cc_epoll 5641 5637 5637 \_ cc_epoll 5642 5637 5637 \_ cc_epoll

       这是自己写的cc_epoll进程，从上面的结果可以看出，父进程fork出5个子进程，其中父进程是进程组组长，子进程的PGID是父进程，那父进程和子进程的PGID在什么时候设置的呢，首先通过strace跟踪一下：

root@jusse ~# strace ps -ef -o pid,ppid,pgid,comm……stat("/proc/5640", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0open("/proc/5640/stat", O_RDONLY)       = 6  read(6, "5640 (cc_epoll) S 5637 5637 2840"..., 1024) = 324read(6, "", 700)                        = 0  close(6)                                = 0  ……

       原来是去读取/proc/5640/stat这个文件的内容啊。那我们就看一下它是怎么read的，在google在搜了一圈都没找到proc文件系统的实现思路，那就只能从read系统调用入手了。我们可以自己cat一下：

root@jusse ~# cat /proc/5640/stat 5640 (cc_epoll) S 5637 5637 28400 34828 5637 4219200 63 0 0 0 0 0 0 0 20 0 1 0 746032770 8626176 30 18446744073709551615 4194304 4200196 140734779287888 140734779166376 140232232810899 0 0 0 0 18446744071581020176 0 0 17 0 0 0 0 0 0 6299160 6299888 32350208 140734779291850 140734779291861 140734779291861 140734779293677 0 

root@jusse ~/systemtap# strace cat /proc/5640/stat……open("/proc/5640/stat", O_RDONLY)       = 3fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0read(3, "5640 (cc_epoll) S 5637 5637 2840"..., 32768) = 324write(1, "5640 (cc_epoll) S 5637 5637 2840"..., 3245640 (cc_epoll) S 5637 5637 28400 34828 5637 4219200 63 0 0 0 0 0 0 0 20 0 1 0 746032770 8626176 30 18446744073709551615 4194304 4200196 140734779287888 140734779166376 140232232810899 0 0 0 0 18446744071581020176 0 0 17 0 0 0 0 0 0 6299160 6299888 32350208 140734779291850 140734779291861 140734779291861 140734779293677 0) = 324read(3, "", 32768)                      = 0close(3)                                = 0……

       用SystemTap定位read系统调用后得到的代码如下：

       从代码可以看出sys_read主要调用vfs_read，vfs_read主要调用file->f_op->read，而这个read是一个指针，要是能gdb step进去一下就知道是哪个函数了，调试nginx时我就经常这么干，可惜这是内核啊，gdb调试内核连环境都要搭半天，太麻烦了划不来。还是用SystemTap吧，SystemTap可以在vfs_read设置个probe，也就是设置一个探测点，SystemTap代码如下：

probe kernel.statement("vfs_read@/build/buildd/linux-lts-trusty-3.13.0/fs/read_write.c:392"){    if ($count == 32768) { //这里设置条件是为了过滤只留下需要的信息，32768是上面用strace跟踪得到read的第三个参数        printf("open: %s, read: %s\n", symname($file->f_op->open), symname($file->f_op->read));    }}

       从SystemTap提供的symname函数接口可以得到指定地址的符号，也就是这小节的技巧：查看实际的函数

       运行stap后再执行cat /proc/5640/stat就可以得到如下结果：

root@jusse ~/systemtap# stap vfs_read.stp open: 0x0, read: inotify_read open: 0x0, read: inotify_read open: proc_single_open, read: seq_read open: proc_single_open, read: seq_read 

       接下来就是分析proc_single_open和seq_read这两个函数了，通过这种方式分析下去，最后也得到进程的PGID是存在什么地方了，具体存在什么地方就略了，你也可以分析一下，从分析的过程中还能学到不少东西呢。

3、查看一个函数里面能在哪一行设置probe以及能获取哪些变量。

       Linux内核的copy_process函数比较长，但被编译器优化了不少，在一些行上设置不了probe或者获取不了局部变量。设置行数不对或者获取不到变量符号就容易得到正面这些错误：

root@jusse ~/systemtap# stap copy_process.stap semantic error: no line records for /build/buildd/linux-lts-trusty-3.13.0/kernel/fork.c:1235 [man error::dwarf] (try :1234 or :1236) semantic error: while resolving probe point: identifier 'kernel' at copy_process.stap:1:7 source: probe kernel.statement("copy_process@/build/buildd/linux-lts-trusty-3.13.0/kernel/fork.c:1235") ^ semantic error: no match Pass 2: analysis failed. [man error::pass2] root@jusse ~/systemtap# stap copy_process.stap semantic error: failed to retrieve location attribute for 'p' [man error::dwarf]: identifier '$p' at copy_process.stap:3:29 dieoffset: 0x9d4ac2 from unknown debug file for kernel function: copy_process at /build/buildd/linux-lts-trusty-3.13.0/kernel/fork.c:1236 source: printf("$p->pid: %d\n", $p->pid); ^ Pass 2: analysis failed. [man error::pass2]

       解决行数设置不对的办法是一是按照错误提示设置，二是用stap的-L参数看能在哪些行上设probe：

root@jusse ~/systemtap# stap -L 'kernel.statement("copy_process@/build/buildd/linux-lts-trusty-3.13.0/kernel/fork.c:*")' kernel.statement("copy_process@/build/buildd/linux-lts-trusty-3.13.0/kernel/fork.c:1134") kernel.statement("copy_process@/build/buildd/linux-lts-trusty-3.13.0/kernel/fork.c:1140") kernel.statement("copy_process@/build/buildd/linux-lts-trusty-3.13.0/kernel/fork.c:1144") $clone_flags:long unsigned int $stack_start:long unsigned int $stack_size:long unsigned int $child_tidptr:int* $pid:struct pid* $trace:int kernel.statement("copy_process@/build/buildd/linux-lts-trusty-3.13.0/kernel/fork.c:1145") $clone_flags:long unsigned int $stack_start:long unsigned int $stack_size:long unsigned int $child_tidptr:int* $pid:struct pid* $trace:int kernel.statement("copy_process@/build/buildd/linux-lts-trusty-3.13.0/kernel/fork.c:1147") $clone_flags:long unsigned int $stack_start:long unsigned int $stack_size:long unsigned int $child_tidptr:int* $pid:struct pid* $trace:int $p:struct task_struct* kernel.statement("copy_process@/build/buildd/linux-lts-trusty-3.13.0/kernel/fork.c:1154") $clone_flags:long unsigned int $stack_start:long unsigned int $stack_size:long unsigned int $child_tidptr:int* $pid:struct pid* $trace:int $p:struct task_struct* kernel.statement("copy_process@/build/buildd/linux-lts-trusty-3.13.0/kernel/fork.c:1162") $clone_flags:long unsigned int $stack_start:long unsigned int $stack_size:long unsigned int $child_tidptr:int* $pid:struct pid* $trace:int $p:struct task_struct* kernel.statement("copy_process@/build/buildd/linux-lts-trusty-3.13.0/kernel/fork.c:1171") $clone_flags:long unsigned int $stack_start:long unsigned int $stack_size:long unsigned int $child_tidptr:int* $pid:struct pid* $trace:int $p:struct task_struct* kernel.statement("copy_process@/build/buildd/linux-lts-trusty-3.13.0/kernel/fork.c:1172") $clone_flags:long unsigned int $stack_start:long unsigned int $stack_size:long unsigned int $child_tidptr:int* $pid:struct pid* $trace:int $p:struct task_struct*

       copy_process函数虽长但能获取的变量也就这么多，试图获取其他变量也会出错。我们要获取copy_process复制出来的task_struct的话只能在第1147、1154、1162、1171、1172这几行上获取$p，而这些行上不一定能执行到，从代码上看在这些行上$p是一个野指针，要在第1192行调用dup_task_struct(current)后才给$p赋值。所以在copy_process函数里设置statement探测点来获取task_struct是获取不到的。那怎么办呢，还好，copy_process函数会把复制出的task_struct返回给调用它的函数，那就可以在copy_process上设置function return探测点：

probe kernel.function("copy_process").return{    printf("pid: %d\n", $return->pid);}

       要是函数没有返回你要找的变量，那就看它有没有把这个函数传给其他函数了，如果传那就在其他函数里面获取，没有的话就只能反汇编这个函数，再看这个函数把这个变量地址放在哪个寄存器上，再通过这个寄存器得到变量的地址来获取这个变量的内容。

4、获取函数参数。

       我们来看一下sys_open的代码：

       再用stap -L来看一下sys_open能设置哪些probe和能获取哪些变量：

root@jusse ~/systemtap# stap -L 'kernel.function("sys_open")' kernel.function("SyS_open@/build/buildd/linux-lts-trusty-3.13.0/fs/open.c:1011") $ret:long introot@jusse ~/systemtap# stap -L 'kernel.statement("sys_open@/build/buildd/linux-lts-trusty-3.13.0/fs/open.c:*")' kernel.statement("SyS_open@/build/buildd/linux-lts-trusty-3.13.0/fs/open.c:1011") $ret:long int kernel.statement("SyS_open@/build/buildd/linux-lts-trusty-3.13.0/fs/open.c:1014") $filename:long int $flags:long int $ret:long int kernel.statement("SyS_open@/build/buildd/linux-lts-trusty-3.13.0/fs/open.c:1016") $filename:long int $ret:long int 

       我们要想获取用户传进来的参数filename怎么办呢，一是在sys_open函数上设置function  call探测点，二是在第1016行设置statement探测点。第二种方法是能获取filename，但获取不到最后一个参数mode。对于函数参数还有一种办法就是用SystemTap提供的*_arg函数接口，*是根据类型指定的，比较pointer_arg是获取指针类型参数，int_arg是获取整型参数，类似的还有long_arg、longlong_arg、uint_arg、ulong_arg、ulonglong_arg、s32_arg、s64_arg、u32_arg、u64_arg，例子代码如下：

root@jusse ~/systemtap# cat sys_open.stp probe kernel.function("sys_open").call{    printf("filename: %p, flags: %d, mode: %x\n", pointer_arg(1), int_arg(2), int_arg(3));}

       这样我们就可以得到函数的指定参数了。

5、打印__user字符串。

       在内核里宏__user是给地址加上一个属性，指定这个地址是用户态地址，在内核里不能直接用，需要转换才能用。我们在SystemTap代码里面不能直接用user_string或者kernel_string，否则运行时出现下面这个错误：

ERROR: user string copy fault -14 at 00007f16323ffd90 [man error::fault] near identifier 'user_string_n' at /usr/local/share/systemtap/tapset/uconversions.stp:120:10

ERROR: kernel string copy fault at 0x00007fde54e79d90 [man error::fault] near identifier 'kernel_string' at /usr/local/share/systemtap/tapset/linux/conversions.stp:18:10

       想要打印__user限定的字符串，比如打印sys_open的第一个参数filename，要像下面这样：

root@jusse ~/systemtap# cat sys_open.stp probe kernel.function("sys_open").call {     filename = user_string_quoted(pointer_arg(1));     printf("filename: %s, execname: %s\n", filename, execname()); } 

6、打印函数调用堆栈。

       一般打印函数调用堆栈，用户进程的话直接gdb上去在文件行数或者函数设置一个断点，等待断点停下来后，用gdb命令backtrace（缩写bt）就能得到调用堆栈了，这样很有用，不管是学习新代码或者debug时都非常有用，比如在学nginx的时候，里面很多函数指针，用source insight、understand、vim+ctag都很难把代码流程读通，还是让代码运行起来后gdb上去设置断点bt一下就知道了。用户进程这种方法很管用，但在内核就不好办了，内核也一堆函数指针，很不好分析函数的调用流程，还好SystemTap给我们提供了print_backtrace，比如我们要看内核是怎么收包的，它的调用流程是怎样的，我们在netif_receive_skb函数上设置个探测点再把调用函数堆栈打印出来就知道了：

root@jusse ~/systemtap# cat netif_receive_skb.stp probe kernel.function("netif_receive_skb") {     printf("--------------------------------------------------------\n");     print_backtrace();     printf("--------------------------------------------------------\n"); } root@jusse ~/systemtap# stap netif_receive_skb.stp-------------------------------------------------------- 0xffffffff8164dc00 : netif_receive_skb+0x0/0x90 [kernel] 0xffffffff8164e280 : napi_gro_receive+0xb0/0x130 [kernel] 0xffffffff81554537 : handle_incoming_queue+0xe7/0x100 [kernel] 0xffffffff815555d9 : xennet_poll+0x279/0x430 [kernel] 0xffffffff8164ee09 : net_rx_action+0x139/0x250 [kernel] 0xffffffff810702cd : __do_softirq+0xdd/0x300 [kernel] 0xffffffff8107088e : irq_exit+0x11e/0x140 [kernel] 0xffffffff8144e785 : xen_evtchn_do_upcall+0x35/0x50 [kernel] 0xffffffff8176c9ed : xen_hvm_callback_vector+0x6d/0x80 [kernel]--------------------------------------------------------

7、定义指定类型的变量。

       我在看SystemTap_Beginners_Guide文档的时候，看到nettop.stp这个例子，就试着运行一下：

root@jusse ~/source/systemtap# stap ./testsuite/systemtap.examples/network/nettop.stp semantic error: not accessible at this address (pc: 0xffffffff8164dc00) [man error::dwarf]: identifier '$skb' at /usr/local/share/systemtap/tapset/linux/networking.stp:64:27 dieoffset: 0x5cb9e3e from unknown debug file for kernel function: netif_receive_skb at /build/buildd/linux-lts-trusty-3.13.0/net/core/dev.c:3694 <cannot suggest any alternative locations, elfutils too old> source: dev_name = kernel_string($skb->dev->name) ^ Pass 2: analysis failed. [man error::pass2]

       出错了，说是$skb找不到，那就看看/usr/local/share/systemtap/tapset/linux/networking.stp这个文件是怎么写的：

       原来是想获取netif_receive_skb函数的参数skb，这个就是上面第4个技巧说的获取函数参数获取不到的情况，那就改成下面这样：

       提前定义一个skb的变量，然后把后面用到$skb的地方改成skb，再运行试试：

root@jusse ~/source/systemtap# stap ./testsuite/systemtap.examples/network/nettop.stp semantic error: unknown type in dereference: operator '->' at /usr/local/share/systemtap/tapset/linux/networking.stp:65:30 source: dev_name = kernel_string(skb->dev->name) ^ Pass 2: analysis failed. [man error::pass2] 

       还是出错，这回是解引用一个不知道类型指针的错误，那用@cast转换一下：

root@jusse ~/source/systemtap# stap ./testsuite/systemtap.examples/network/nettop.stp semantic error: 'struct sk_buff' is being accessed instead of a member: operator '@cast' at /usr/local/share/systemtap/tapset/linux/networking.stp:64:11 source: skb = @cast(pointer_arg(1), "struct sk_buff") ^ Pass 2: analysis failed. [man error::pass2] 

       还是出错，这回是@cast的错误了，难道@cast不能这么用？原来@cast应该这么用：

root@jusse ~/source/systemtap# stap ./testsuite/systemtap.examples/network/nettop.stp PID UID DEV XMIT_PK RECV_PK XMIT_KB RECV_KB COMMAND 0 0 eth1 7 357 0 14 swapper/0 0 0 eth0 0 12 0 0 swapper/0 3 0 eth1 0 2 0 0 ksoftirqd/0 9838 0 eth1 0 2 0 0 redis-server 8 0 eth1 0 1 0 0 rcuos/0

       这回是成功了，但每次都@cast一下，很费事啊，难道就不能提前声明定义一下吗，寻觅了(grep -nr @cast ./)它的所有例子，看看@cast还有没有其他用法，最终还是找到一个可行的办法，再改一下：

       这回也成功了，所以得到结论就是，@cast是可以提前定义指定类型变量的，原理就是先取变量第0个数组元素（其实就是自身）再对自身取地址就是指针变量了。

8、多级指针用法。

       之前写过一个SystemTap多级指针解引用的办法：http://blog.csdn.net/wangzuxi/article/details/40323213

function deref:long(ptr:long)%{    STAP_RETURN(*(void **)STAP_ARG_ptr);%}

       但最近发现一个更简单的方法，从第7个技巧得到的灵感，看看下面二级指针用法的例子吧：

root@jusse ~/develop# cat cc_multi_pointer.c#include <stdio.h>struct test {    int count;};int main(int argc, char *argv[]){       struct test t = {.count = 5566};    struct test *pt = &t;    struct test **ppt = &pt;    printf("t.count: %d, pt->count: %d, ppt->count: %d\n", t.count, pt->count, (*ppt)->count);    return 0;}root@jusse ~/develop# gcc -Wall -g -o cc_multi_pointer ./cc_multi_pointer.croot@jusse ~/develop# cat cc_multi_pointer.stpprobe process("./cc_multi_pointer").statement("main@./cc_multi_pointer.c:13"){       printf("$t->count: %d, $pt->count: %d, $ppt->count: %d", $t->count, $pt->count, $ppt[0]->count);}root@jusse ~/develop# ./cc_multi_pointert.count: 5566, pt->count: 5566, ppt->count: 5566root@jusse ~/develop# stap ./cc_multi_pointer.stp -c './cc_multi_pointer't.count: 5566, pt->count: 5566, ppt->count: 5566$t->count: 5566, $pt->count: 5566, $ppt->count: 5566root@jusse ~/develop# vim cc_multi_pointer.stproot@jusse ~/develop# 

       现在三级指针你应该知道怎么搞了吧。

9、嵌入C语言代码。

       这个技巧很有用，可以获取各种信息，而且可以调用内核函数，比如我们想在进程fork出子进程时打印出进程id和进程名，也是先看看例子吧：

root@jusse ~/systemtap# cat copy_process.stpfunction getprocname:string(task:long)%{    struct task_struct *task = (struct task_struct *)STAP_ARG_task;    snprintf(STAP_RETVALUE, MAXSTRINGLEN, "pid: %d, comm: %s", task->pid, task->comm);%}function getprocid:long(task:long)%{    struct task_struct *task = (struct task_struct *)STAP_ARG_task;    STAP_RETURN(task->pid);%}probe kernel.function("copy_process").return{    printf("copy_process return: %p, pid: %d, getprocname: %s, getprocid: %d\n", $return, $return->pid, getprocname($return), getprocid($return));}root@jusse ~/systemtap# stap -g copy_process.stpcopy_process return: 0xffff880039f61800, pid: 12212, getprocname: pid: 12212, comm: bash, getprocid: 12212copy_process return: 0xffff880039f61800, pid: 12212, getprocname: pid: 12212, comm: bash, getprocid: 12212copy_process return: 0xffff880039f63000, pid: 12213, getprocname: pid: 12213, comm: cc_epoll, getprocid: 12213copy_process return: 0xffff880039f63000, pid: 12213, getprocname: pid: 12213, comm: cc_epoll, getprocid: 12213copy_process return: 0xffff8800081a9800, pid: 12214, getprocname: pid: 12214, comm: cc_epoll, getprocid: 12214copy_process return: 0xffff8800081a9800, pid: 12214, getprocname: pid: 12214, comm: cc_epoll, getprocid: 12214copy_process return: 0xffff8800004d8000, pid: 12215, getprocname: pid: 12215, comm: cc_epoll, getprocid: 12215copy_process return: 0xffff8800004d8000, pid: 12215, getprocname: pid: 12215, comm: cc_epoll, getprocid: 12215copy_process return: 0xffff880000564800, pid: 12216, getprocname: pid: 12216, comm: cc_epoll, getprocid: 12216copy_process return: 0xffff880000564800, pid: 12216, getprocname: pid: 12216, comm: cc_epoll, getprocid: 12216copy_process return: 0xffff880000566000, pid: 12217, getprocname: pid: 12217, comm: cc_epoll, getprocid: 12217copy_process return: 0xffff880000566000, pid: 12217, getprocname: pid: 12217, comm: cc_epoll, getprocid: 12217

       有三个需要注意的地方：

       1）、SystemTap脚本里面嵌入C语言代码要在每个大括号前加%前缀，是%{…… %}  而不是%{ …… }%；

       2）、获取脚本函数参数要用STAP_ARG_前缀；

       3）、一般long等返回值用STAP_RETURN，而string类型返回值要用snprintf、strncat等方式把字符串复制到STAP_RETVALUE里面。

SystemTap的技巧还有很多，以后有空再写。

附：

root@jusse ~/systemtap# uname -aLinux jusse 3.13.0-36-generic #63~precise1-Ubuntu SMP Thu Sep 4 22:28:20 UTC 2014 x86_64 x86_64 x86_64 GNU/Linuxroot@jusse ~/systemtap# stap -VSystemtap translator/driver (version 2.7/0.152, commit release-2.6-65-g89538c0b970d)Copyright (C) 2005-2014 Red Hat, Inc. and othersThis is free software; see the source for copying conditions.enabled features: TR1_UNORDERED_MAP NLS

参考：

https://sourceware.org/systemtap/tutorial/

https://sourceware.org/systemtap/tapsets/

https://sourceware.org/systemtap/man/

http://blog.csdn.net/linyt/article/category/645022

http://segmentfault.com/blog/yexiaobai/1190000000680628

http://blog.csdn.net/zhangskd/article/details/27320965