为啥systemtap没找到函数
hon@station6:~/codebox/stap/net$ sudo stap -L 'kernel.function("sock_recvmsg_nosec")'
kernel.function("sock_recvmsg_nosec@/build/linux-Ay7j_C/linux-4.4.0/net/socket.c:710")
710 static inline int sock_recvmsg_nosec(struct socket *sock, struct msghdr *msg,
711 size_t size, int flags)
712 {
713 return sock->ops->recvmsg(sock, msg, size, flags);
714 }
这是很好的一个例子,函数中明明是有sock msg size flags,但是stap显示不了,这说明函数被优化过了,
但是没有变量信息,说明这个参数直接被优化掉了
难道不是edi/esi中存放的就不是第一个参数了?
gcc如何优化函数入参:windows和linux是不同的:
https://www.cnblogs.com/shangdawei/p/3323252.html
那么函数参数什么时候会被优化呢?
我ubuntu机器上vmlinux的路径是/usr/lib/debug/boot目录下面,我们看一下这段反汇编代码的样子:
7 ffffffff816fb700 <sock_recvmsg_nosec>:
8 ffffffff816fb700: 48 8b 47 28 mov 0x28(%rdi),%rax
9 ffffffff816fb704: 55 push %rbp
10 ffffffff816fb705: 48 89 e5 mov %rsp,%rbp
11 ffffffff816fb708: ff 90 90 00 00 00 callq *0x90(%rax)
12 ffffffff816fb70e: 5d pop %rbp
13 ffffffff816fb70f: c3 retq
好好分析下这段汇编代码还真是有问题呢,首先我们通过gdb发现0x28(%rdi) 这个地方的值就是是:$sock->ops呢,也就是说rax寄存器中的值就是,
(gdb) p &((struct socket *)0)->ops
$2 = (const struct proto_ops **) 0x28 <irq_stack_union+40>
(gdb) p &((struct proto_ops *)0)->recvmsg
$3 = (int (**)(struct socket *, struct msghdr *, size_t,
int)) 0x90 <irq_stack_union+144>
这段汇编代码中两个非常关键的常数:0x28,0x90我们就知道是啥了, 第一步是$sock->ops嘛,然后第二部就是($sock->ops)->recvmsg,然后取数值,就得到真正的recv_msg的地址咯,所以直到调用函数unix_stream_recvmsg,应该edi/esi都不变才对呢,为啥就变了呢,看下参数是怎么传递的:
来个普通的func(int a, int b)函数是怎么传递参数的
273 00000000004004d6 <func>:
274 4004d6: 55 push %rbp
275 4004d7: 48 89 e5 mov %rsp,%rbp
276 4004da: 89 7d fc mov %edi,-0x4(%rbp)
277 4004dd: 89 75 f8 mov %esi,-0x8(%rbp)
...................
281 4004e7: c3 retq
282
283 00000000004004e8 <main>:
..................
287 4004f0: be 02 00 00 00 mov $0x2,%esi
288 4004f5: bf 01 00 00 00 mov $0x1,%edi
289 4004fa: e8 d7 ff ff ff callq 4004d6 <func>
290 4004ff: 89 45 fc mov %eax,-0x4(%rbp)
291 400502: b8 01 00 00 00 mov $0x1,%eax
292 400507: c9 leaveq
293 400508: c3 retq
294 400509: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
即便是优化了,参数也是放在了edi/esi中,那么我读取这个寄存器咋就不行呢?
程序为了优化,在sock_recvmsg_nosec上下文中根本就看不到edi/esi/edi,
710 static inline int sock_recvmsg_nosec(struct socket *sock, struct msghdr *msg,
711 size_t size, int flags)
712 {
713 return sock->ops->recvmsg(sock, msg, size, flags); //
714 }
但是这里我觉得edi/esi/参数仍然是存在的于寄存器edi中,只不过在这个上下文中不存在,所以在这里我们用ktap中两种方法中第一个参数的值;
1)ulong_arg(1)
2) 直接读取寄存器edi register("edi")
结果发现惊人地相似:
regis: 0xffffffff81d5d210
ulong: 0xffffffff81d5d210
regis: 0xffffffff81d5d210
ulong: 0xffffffff81d5d210
regis: 0xffffffff81d5d210
ulong: 0xffffffff81d5d210
regis: 0xffffffff81d5d210
ulong: 0xffffffff81d5d210
发现大家指向的都是一样的 1) ulong_arg(1) 2) pointer_arg(1); (3) register("edi")
为啥子,在函数中遇到的值不是一样的咧。
在函数调用关系中sock_recvmsg->sock_recvmsg_nosec->unix_stream_recvmsg
发现在函数sock_recvmsg和函数unix_stram_recvmsg中得到的函数的变量是一致的!!只有在sock_recvmsg_nosec中得到的变量与他们相差好大,这是因为sock_recvmsg_nosec是inline函数吗?但是inline函数怎么/proc/kallsyms中也能看到呀,并且
ffffffff816fb700 t sock_recvmsg_nosec
ffffffff816fdb30 T sock_recvmsg
hello inline:0xffffffff816fdb55 sock_recvmsg
hello inline:0xffffffff816fdb55 sock_recvmsg
hello inline:0xffffffff816fdb55 sock_recvmsg
hello inline:0xffffffff816fdb55 sock_recvmsg
hello inline:0xffffffff816fdb55 sock_recvmsg
hello inline:0xffffffff816fdb55 sock_recvmsg
hello inline:0xffffffff816fdb55 sock_recvmsg
hello inline:0xffffffff816fdb55 sock_recvmsg
hello inline:0xffffffff816fdb55 sock_recvmsg
发现根本就不是函数sock_recvmsg_nosec,而是函数probefunc()
7 probe kernel.function("sock_recvmsg_nosec").inline {
8 printf("hello inline:%p %s\n", addr(), probefunc())
9 }
并且输出的地址也不是sock_recvmsg_nosec,直接就是函数sock_recvmsg了,根本就没有上下文信息,所以现在的问题是为啥inline函数有单独的程序块?
inline函数是有单独的程序块,但是真正程序执行时是不会跳到这个块里的,这个块就是为了将来直接嵌入到caller中去,看下caller的汇编码就可以了
反汇编函数的代码有:真正程序执行是调用的函数调用在0x816fdb55这个地方,
7 ffffffff816fdb30 <sock_recvmsg>:
8 ffffffff816fdb30: e8 7b 90 12 00 callq ffffffff81826bb0 <__fentry__>
9 ffffffff816fdb35: 55 push %rbp
10 ffffffff816fdb36: 48 89 e5 mov %rsp,%rbp
11 ffffffff816fdb39: 41 56 push %r14
12 ffffffff816fdb3b: 41 55 push %r13
13 ffffffff816fdb3d: 41 54 push %r12
14 ffffffff816fdb3f: 53 push %rbx
15 ffffffff816fdb40: 49 89 f4 mov %rsi,%r12
16 ffffffff816fdb43: 48 89 fb mov %rdi,%rbx
17 ffffffff816fdb46: 49 89 d5 mov %rdx,%r13
18 ffffffff816fdb49: 41 89 ce mov %ecx,%r14d
19 ffffffff816fdb4c: e8 3f 18 c4 ff callq ffffffff8133f390 <security_socket_recvmsg>
20 ffffffff816fdb51: 85 c0 test %eax,%eax
21 ffffffff816fdb53: 75 16 jne ffffffff816fdb6b <sock_recvmsg+0x3b>
22 ffffffff816fdb55: 48 8b 43 28 mov 0x28(%rbx),%rax
23 ffffffff816fdb59: 44 89 f1 mov %r14d,%ecx
24 ffffffff816fdb5c: 4c 89 ea mov %r13,%rdx
25 ffffffff816fdb5f: 4c 89 e6 mov %r12,%rsi
26 ffffffff816fdb62: 48 89 df mov %rbx,%rdi
27 ffffffff816fdb65: ff 90 90 00 00 00 callq *0x90(%rax)
28 ffffffff816fdb6b: 5b pop %rbx
29 ffffffff816fdb6c: 41 5c pop %r12
30 ffffffff816fdb6e: 41 5d pop %r13
31 ffffffff816fdb70: 41 5e pop %r14
32 ffffffff816fdb72: 5d pop %rbp
33 ffffffff816fdb73: c3 retq
34 ffffffff816fdb74: 66 90 xchg %ax,%ax
35 ffffffff816fdb76: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
36 ffffffff816fdb7d: 00 00 00
在红色插入点的位置,可见,其实rdi/rsi/rdx/rcx的值可能已经被函数给换掉了,所以不能够使用了已经。