在某次调用栈的采集中,我们发现调用栈少了一层,如下是我们的调用示例代码:
我们通过如下的命令进行编译:
按照我们的理解,这里采集到的调用栈应该会出现main() -> foo() -> bar()
的调用栈,但是在实际采样中,我们发现采集到的是如下的调用栈:
从调用栈里我们会发现少了bar()
函数而是直接到了malloc
函数,这是怎么回事呢?
需要先了解程序运行时栈的相关流程,如果不了解的同学可以先去了解一下。简单的说就是系统借助栈来进行函数调用。
首先我们让ChatGPT
给我们介绍一些相关的概念:
fp
:frame pointer
,帧指针,指在函数调用过程中用于定位和访问函数栈帧的指针。它指向当前函数的栈帧的起始位置,栈帧包含了函数的局部变量、参数以及其他与函数执行相关的信息。通过帧指针,程序可以在运行时准确地访问和管理函数的局部数据。帧指针通常是在编译器生成的汇编代码中使用,并且在调试和性能分析中也经常被使用。stack frame
,是指在函数调用过程中,为了维护函数的局部变量、参数以及其他与函数执行相关的信息而在运行时创建的一块连续的内存空间。每当一个函数被调用时,就会在程序的栈空间中创建一个新的栈帧,用于存储该函数的局部变量、参数以及其他必要的信息。当函数执行完毕后,它的栈帧会被销毁,从而释放相应的内存空间:<img src="https://cos-1257346011.cos.ap-nanjing.myqcloud.com/image-20231026205732600.png" alt="栈帧 - https://www.huamo.online/2019/06/25/%E6%B7%B1%E5%85%A5%E7%A0%94%E7%A9%B6goroutine%E6%A0%88/" style="zoom:67%;" />
32
位机器会减少4
字节。在讲述中,我们统一将
SP/RSP/ESP
寄存器介绍为RSP
,BP/RBP/EBP
寄存器介绍为RBP
,以32位机器为例,并且不考虑返回地址等信息。
在前文中的图中,我们可以看到RSP
寄存器是栈指针,指向栈顶的位置;而最常见的一种栈回溯方式是通过RBP
寄存器来记录下上层调用者的RSP
指针的值来进行栈回溯的。
具体是怎么实现的呢?我们通过结合main -> foo -> bar
的汇编和调用来进行讲解。首先,我们假设当前是main
函数:
接着,main
函数通过call
命令去调用foo
函数,foo
汇编如下所示:
在call
命令执行的时候,会将返回地址压进去;此外可以看到这里通过push
操作将RBP
寄存器压栈了,此时RSP
会发生变化,并且将此时RSP
的值放到了RBP
中,如图所示:
也即:在调用后,系统会将调用者的**RBP
**记录到栈中,并更新**RBP
**为当前函数的**RSP
**留给下次被调用的函数使用。RBP总是保存栈中的地址。
接着,foo
函数会去调用bar
,bar
函数的汇编如下图所示:
也是和foo
的调用一致,会先将RBP
压栈并设置RBP = RSP
,此时的调用栈情况:
那么,我们怎么去进行栈回溯呢?
当抓到当前的运行地址时,可以通过当前的RBP
找到栈中的记录的的地址,从而一层层的向上回溯:
那能找到RBP
信息以后我们该如何进行函数的判断呢?我们注意到RBP
是被调用函数首先执行的部分,而调用函数会通过call
来调用,call
的时候会压入返回地址,这个返回地址肯定是属于调用函数的,我们可以基于这个来进行判断。例如在main
调用foo
的时候,压入的地址肯定是在main
函数中的,所以我们在foo
的部分可以向上找到返回地址,从而判断foo
是被谁调用的。
此处进行地址和函数转换的时候需要调试信息(debug info),否则会找不到函数名。
因此,整个栈回溯流程就变成了:
基于这个回溯流程,我们就可以得到bar -> foo -> main
的回溯,反一下就是相应的调用栈了。
我们可以得出一个结论:只有被调用函数才能保存调用函数信息。也即bar
函数是由foo
函数来协助找到的。
为了解决前面提到的问题,我们对二进制进行了反汇编:
objdump -d -S back > back.asm
在bar
函数中,我们发现其调用了下一级函数:
我们去查看这个地址的信息:
我们发现这里并没有去和前几次调用一样去做push %rbp
的操作,结合我们前文所说,从这里进行栈回溯的时候就自然而然的不能找到bar
函数了,如图所示:
这里我们假设该函数为malloc。可以设想后续的调用如果没有压栈RBP的操作的话都是一致的。
那么为什么这里没有做压栈操作呢?这是因为push %rbp
和mov %rsp,%rbp
是实实在在写在汇编代码中的,如果每次调用都执行的话会带来性能损耗,也即通过**frame pointer
**方式获取调用栈会多执行指令,会带来一定的性能损耗。因此在实际场景中,都默认不编译这两条汇编,例如在g++
中如果要携带这类信息需要通过-fno-omit-frame-pointer
选项来保留frame pointer
信息。这里我们自己编写的代码是通过-fno-omit-frame-pointer
选项进行编译的,但是在调用标准库的时候,标准库的代码并不一定是通过-fno-omit-frame-pointer
编译的,因此可能会出现缺少某一层调用栈的情况。
例如我们通过-fomit-frame-pointer
选项编译了同样的代码,其中foo
函数的汇编如下图:
本文主要基于一个消失的调用栈的例子,分析了基于fp
的栈回溯的原理。然而,在实际的生产环境中,很多时候都是不开启-fno-omit-frame-pointer
选项的,那这个时候我们该如何去做调用栈分析呢?我们下一篇文章再介绍别的栈回溯方式与原理。
我正在参与2023腾讯技术创作特训营第三期有奖征文,组队打卡瓜分大奖!
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。