为啥ｓｙｓｔｅｍｔａｐ没找到函数
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
那么函数参数什么时候会被优化呢？
我ｕｂｕｎｔｕ机器上ｖｍｌｉｎｕｘ的路径是/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
好好分析下这段汇编代码还真是有问题呢，首先我们通过ｇｄｂ发现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中，只不过在这个上下文中不存在，所以在这里我们用ｋｔａｐ中两种方法中第一个参数的值；
１）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函数是有单独的程序块，但是真正程序执行时是不会跳到这个块里的，这个块就是为了将来直接嵌入到ｃａｌｌｅｒ中去，看下ｃａｌｌｅｒ的汇编码就可以了
反汇编函数的代码有：真正程序执行是调用的函数调用在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/rｃｘ的值可能已经被函数给换掉了，所以不能够使用了已经。
