写个dump_stack

最新推荐文章于 2025-07-02 19:03:54 发布
最新推荐文章于 2025-07-02 19:03:54 发布
阅读量4.7k 收藏 4
点赞数
CC 4.0 BY-SA版权
分类专栏： kernel hacking 文章标签： thread module google exception x86 c
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/chobit_s/article/details/6212109
本文详细介绍如何自制dump_stack函数，解析其工作原理，并提供了一个适用于2.6.31.5-127.fc12.i686.PAE内核版本的实现案例。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

简单实现dump_stack
0.首先确保你能写个内核模块:打印"hello kernel"
  如果熟悉dump_stack的话，完全可以绕开此文，或者自己去看dump_stack代码实现之。
 
1.dump_stack是什么
经常调试内核一定对这个函数不陌生，因为我们大多数人调试内核的时候都受这个函数的
折磨，不信，那么我们调用下这个函数看看(随意写个内核模块调用dump_stack()，插入内核),
我们来看看输出:
Pid: 9982, comm: insmod Not tainted 2.6.31.5-127.fc12.i686.PAE #1
Call Trace:
 [<f7e98008>] init+0x8/0xc [hello]
 [<c040305b>] do_one_initcall+0x51/0x13f
 [<c0462e2f>] sys_init_module+0xac/0x1bd
 [<c0408f7b>] sysenter_do_call+0x12/0x28
看到输出，大家一定很熟悉, 没见过类似输出的，一定没把kernel搞崩过.
(来我教你:*(int *)NULL = 0xdead;)
其实不见得每次内核崩溃都会调用dump_stack，但是看到dump_stack的我们不应该被吓到，
反而应该高兴：内核在临挂前还喘口气给我们提示了宝贵的调试信息
 
2.构造dump_stack第一句
有的人已经不耐烦我这唠叨，自己开始查看代码了,但是为了满足我们小小的虚荣，看懂还不行，
自己也要来写个玩玩,不能老被dump_stack欺负阿。
我们看看dump_stack里面第一句代码：
 printk("Pid: %d, comm: %.20s %s %s %.*s/n",
                 current->pid, current->comm, print_tainted(),
                 init_utsname()->release,
                 (int)strcspn(init_utsname()->version, " "),
                 init_utsname()->version);
这里就不解释printk每个参数了，代码本身就自解释了，剩下的请google，
对于不太理解print_tainted,请看下此函数实现的源码上方的注释：）
 
3.构造dump_stack的call trace
1)先来句printk("Call Trace:/n"),
 
2)接下来就神奇了，当初我就觉得能将函数执行流打印出来实在是很神奇，内核到底用了什么方法呢？
先不说，我们来看一句简单的代码：
printk("[<%p>] %pS/n", &printk, &printk);
观察输出:
[<c0776cf4>] printk+0x0/0x1c
你发现，这个输出结果和dump_stack输出的部分惊人的相似，但是我们传给printk的参数是确确实实的
地址值，原来prink自己能转换地址到相应的函数名，只要用参数"%pS"就可以了。
我相信看到这里的人，估计已经走开自己去实现dump_stack玩了。
但是输出也可能是：
[<c0776cf4>] c0776cf4S
如果你不幸看到这个，那么你还是升级下内核吧，或者仔细阅读下dump_stack代码，完全靠自己去实现
下，那么你收获一定会远超出这篇文章。
printk之所以能够识别函数地址，靠的是kallsyms子系统的帮助，
用过类似grep -w "printk" /proc/kallsyms命令的人，一定要好好谢谢这个子系统，
多亏它我们才能从内核导出symbol
深入研究kallsyms就靠大家了。
 
3)在刚刚的惊喜后，我们回到正题，怎么用printk把当前的执行流打印出来？
这里用到x86中堆栈对函数调用的帮助，详细信息请google，我们要知道一点：每次函数调用时候，
都会将函数的返回地址(调用函数指令的下一句指令的地址)压入堆栈，已备函数返回时。
我们就可以靠这个返回地址来帮助打印函数执行流。
但是这个地址并不是一个函数的准确地址呀？
%pS需要的参数不一定是准确的函数地址，在函数内部任意指令地址都可以，这就解释了输出形式是
"printk+0x0/0x1c"，0x0表示参数地址相对于printk地址的偏移，0x1c表示printk函数大小。
你可以尝试下：printk("%pS/n", &printk + 1);
 
并且如果函数属于某个模块，还会在输出后面加上模块名称，类似：" [<f8cd40a5>] exit+0xd/0xf [hello]"
 
这里知道地址在堆栈里，那么怎么取堆栈呢?
其实很简单：
int stack_pointer;
我们只要取临时变量地址值 &stack_pointer 就可以了(也可以用内联汇编取esp值)，然后只要循环遍历堆栈上所有值，然后判断该值是否在
内核代码段空间内，如果是那么就用%pS输出。
 
那么堆栈的结束地址是什么呢？
就是当前进程的内核态堆栈段，不懂的话请google，一定要搞清除这个。
这里我们记堆栈底为:
bottom = (unsigned int)current_thread_info() + THREAD_SIZE;
 
但是怎么判断地址值是否在内核代码段呢？
我们可以用kernel_text_address这个函数就可以了，但是很不幸的是此函数内核没有导出，我们不能使用，
那么我们就自己实现个kernel_text_address吧，但是更不幸的是此函数内部实现所依赖的变量_etext等也没有
被内核导出，其实我也没想到很好的方法，索性就用个笨办法:
手动找出此函数内核中的地址，
# grep kernel_text_address /proc/kallsyms
c044f107 T kernel_text_address
在代码中通过地址值调用kernel_text_address
int (*kernel_text_addressp)(unsigned int) = (int (*)(unsigned int))0xc044f107;
 
4)给出个较为完整的代码(在本机上写的：2.6.31.5-127.fc12.i686.PAE, 虚拟机上文档写的麻烦)
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/utsname.h>
 
/* 
 * change the value to real addr of kernel_text_address :
 * grep -w kernel_text_address /proc/kallsyms
 */
static int (*kernel_text_addressp)(unsigned int) = (int (*)(unsigned int))0xc044f107;
 
void my_dump_stack(void)
{
unsigned int stack;
unsigned int bottom;
unsigned int addr;
printk("Pid: %d, comm: %.20s %s %s %.*s/n",
current->pid, current->comm, print_tainted(),
init_utsname()->release,
(int)strcspn(init_utsname()->version, " "),
init_utsname()->version); 
printk("Call Trace:/n");
 
/* get stack point */
stack = (unsigned int)&stack;
 
/* get stack bottom point */
bottom = (unsigned int)current_thread_info() + THREAD_SIZE;
 
for (; stack < bottom; stack += 4) {
addr = *(unsigned int *)stack;
if (kernel_text_addressp(addr))
printk(" [<%p>] %pS/n", (void *)addr, (void *)addr);
}
}
 
static int __init init(void)
{
/* test */
my_dump_stack();
return 0;
}
 
static void __exit exit(void)
{
/* test */
my_dump_stack();
}
 
MODULE_LICENSE("GPL");
module_init(init);
module_exit(exit);
 
3.改进
1)
如果你还没厌烦的话，这里有个改进的地方。
你会发现内核中的dump_stack会又类似如下输出：
 [<c04cf4e6>] ? path_put+0x1a/0x1d
这里有个问号：这个表示堆栈中有确有此值(某个函数内部地址)，但是并不代表此函数被
执行，也许这个值是个临时变量寄存在堆栈中。
要区分这个很容易，只要比较地址值所在堆栈的位置是否紧贴当前函数栈空间底的上方，
可以利用ebp(记录当前堆栈底)指针值来作比较，代码就留给大家写了。
 
2)
x86 64 实现要比x86 32复杂(见内核注释)：
/*
 * x86-64 can have up to three kernel stacks:
 * process stack
 * interrupt stack
 * severe exception (double fault, nmi, stack fault, debug, mce) hardware stack
 */
 
4.后记
你可能认为作者在忽悠你，这就整一个dump_stack注释的文章呀，贯上了写dump_stack的头衔！
我只有一句话：
Just for fun！
linux dump_stack
嵌入式Linux
06-27 1423
dump_stack():打印出10条函数的调用关系。 定位故障代码:arm-eabi-gdb out/target/product/msm8625/obj/KERNEL_OBJ/vmlinuxgdb) l * i2c_device_probe+0xc4
Linux内核中dump_stack()的实现机制及其调试应用
数字人生
06-03 225
dump_stack()是Linux内核开发与调试中的关键工具，用于打印当前任务的内核调用栈信息，帮助开发者定位代码执行路径，尤其在处理内核崩溃、竞态条件或驱动异常时不可或缺。其核心功能包括捕获栈帧地址、符号解析和日志输出。在Linux 4.19内核中，dump_stack()的通用实现位于lib/dump_stack.c，处理多核环境下的同步问题，通过原子锁确保单核执行，避免日志混乱。dump_stack()的调用链最终触发架构特定的栈展开逻辑，如x86架构的帧指针或ORC机制。dump_stack()广
linux内核调试技巧之一 dump_stack
龙图腾的博客
07-23 2万+
在内核中代码调用过程难以跟踪，上下文关系复杂，确实让人头痛 调用dump_stack()就会打印当前cpu的堆栈的调用函数了。 如此，一目了然的就能看到当前上下文环境，调用关系了
linux show stack/dump_stack函数分析
陌上花开缓缓归以的博客
07-02 387
函数用于打印当前进程或指定进程的内核态堆栈信息。其核心功能是回溯函数调用栈，并打印出每个函数的地址。// 调用汇编函数回溯栈。是内核调试的重要工具。
dump_stack
liaokesen168的博客
10-21 560
linux内核驱动调试： dump_stack()堆栈打印。。。 待完善！！！！！！！！
dump_stack()
沧浪之水
11-19 982
刚刚接触内核，在调试过程中用printk打印信息当然是直接有效的办法，但当我们不知到一个函数或者一个模块到底在哪里出了问题时我们可以利用dump_stack有效的找到问题的根源，下面只是简单的给出了使用方法。   我在自己的主机上试了一下dump_stack() Makefile文件 点击(此处)折叠或打开 obj-m := hello.o KERNE
linux 应用程序 dump stack,内核中dump_stack()的实现，并在用户态模拟dump_stack()
weixin_35334000的博客
05-05 1112
内核中的dump_stack()获得内核中当前进程的栈回溯信息需要用到的最重要的三个内容就是：栈指针：sp寄存器，用来跟踪程序执行过程。返回地址：ra寄存器，用来获取函数的返回地址。程序计数器：epc，用于定位当前指令的位置。本文的内容都是基于mips体系架构的，如果你不搞mips，就只看个大致流程就可以了，不然可能会被某些内容误导。在ARM中，这三个寄存器分别为SP、LR和PC寄存器。dump_...
dump_stack 实现分析
sunshineywz的博客
05-21 3250
1 简介 说起 dump_stack() ，相信从事 Linux 内核或者驱动相关开发的同行对于此函数肯定不陌生。我们经常会用到此函数来对自己的代码进行 debug，可以快速帮助开发者理清函数调用流程，或者说解决 bug…… 首先我们来看一下 dump_stack 的打印，相信很多人都遇到过 : [258:charger_thread]CPU: 1 PID: 258 Comm: charger_t...
[RK3568 Android11] 教程之kernel源码分析利器dump_stack
~未来可期~
02-07 1657
目录 前言 一、dump_stack使用 二、dump_stack原理 前言 相信从事 Linux 内核或者驱动相关开发的人员对于dump_stack()函数并不陌生，时常使用该函数来跟踪kernel源码和debug分析问题，快速的理清函数之间的调用关系； 一、dump_stack使用 1、当需要分析函数之间调用关系时，只需要把dump_stack()放到该函数里，当运行到该函数时，系统会在debug串口打印出函数之间的调用栈关系； 2、使用方法 只需在需要...
【Linux】内核调用栈打印函数dump_stack使用效果
11-15 475
【代码】【Linux】内核调用栈打印函数dump_stack使用效果。
自动写DUMP
07-22
VS系列开发应用软件，将该头文件添加到代码中，程序崩溃后会自动写一个dmp文件，里面纪录了程序崩溃前的堆栈信息方便程序员查询原因
dump_stack( )
天使之翼
03-07 852
dump_stack()函数可以让其放置的函数的调用栈打印出来，对于定位问题很有帮助。
简略写dump文件
Keivin
03-27 3192
#include #include //DUMP文件 LONG WINAPI MyUnhandledExceptionFilter(struct _EXCEPTION_POINTERS* ExceptionInfo) { CString strFileName = ""; tm* local; time_t t; t=time(NULL); local=localt
【Linux内核调试-dump_stack】
cddchina的专栏
06-07 1534
Linux内核调试
linux 内核调试(dump_stack)
hunanchenxingyu的专栏
05-26 2873
刚刚接触内核，在调试过程中用printk打印信息当然是直接有效的办法，但当我们不知到一个函数或者一个模块到底在哪里出了问题时我们可以利用dump_stack有效的找到问题的根源，下面只是简单的给出了使用方法。   我在自己的主机上试了一下dump_stack() Makefile文件 点击(此处)折叠或打开 obj-m := hello.o
linux内核调试技巧 dump_stack()
路过的熊的博客
03-19 5528
linux内核提供函数dump_stack()来跟踪函数的调用过程，原理是通过打印当前cpu的堆栈的调用函数来显示当前的上下文环境与调用关系； 例： 创建一个混杂设备，并定义read函数。在read中加入dump_stack()，显示read调用关系。结果如下： <1>[ 950.351269] --------------[fyl] dump_stack start---------------- [ 1560.465491] CPU: 0 PID: 2759 Comm: cat Taint
dump_stack()使用方法
热门推荐
Andy的博客
05-20 3万+
dump_stack调试方法。
dump_stack依赖什么头文件
最新发布
07-29
<think>我们正在查找dump_stack函数所需的头文件。根据引用[4]中的代码示例，我们可以看到在模块中使用了dump_stack()函数，并且包含了以下头文件： #include <linux/module.h> #include <linux/init.h> #include <linux/kprobes.h> #include <asm/traps.h> 在示例代码中，dump_stack()函数被直接调用，没有额外的头文件包含说明。但是，根据内核编程经验，dump_stack()函数通常定义在<linux/sched.h>头文件中，或者通过其他头文件间接包含。 然而，在引用[4]的代码中，并没有包含<linux/sched.h>，而是包含了<linux/kprobes.h>和<asm/traps.h>。这可能是因为在特定的内核版本中，dump_stack()的声明被移动到了其他头文件，或者这些头文件间接包含了声明。 但是，为了准确起见，我们应参考最新的内核源代码或官方文档。根据Linux内核源代码，dump_stack()函数通常在<linux/printk.h>或<linux/sched.h>中声明。不过，在较新的内核版本中，它被移到了<linux/printk.h>。 然而，根据引用[2]中的描述，dump_stack()函数用于打印堆栈信息，其实现依赖于/proc/kallsyms等机制。因此，为了确保可移植性，我们应该参考当前内核版本的文档。 但是，用户提供的引用中并没有直接说明头文件。因此，我们可以从示例代码中推断，至少包含<linux/init.h>和<linux/module.h>是必要的，因为模块初始化需要它们。而dump_stack()函数可能不需要直接包含额外的头文件，因为<linux/module.h>可能已经包含了它，或者通过其他头文件间接包含。 然而，为了安全起见，我们可以建议用户包含<linux/printk.h>，因为dump_stack()本质上是一个打印函数，而<linux/printk.h>包含了内核打印函数的声明。此外，在较新的内核中（例如4.x以上），dump_stack()在<linux/printk.h>中声明。 因此，我们可以总结如下： 在Linux内核模块中使用dump_stack()函数，通常需要包含以下头文件： - <linux/module.h>：用于模块初始化。 - <linux/init.h>：用于模块初始化和退出函数的宏。 - <linux/printk.h>：包含dump_stack()的声明（在较新内核中）。 在引用[4]的代码中，还包含了<linux/kprobes.h>和<asm/traps.h>，但这可能是因为该模块使用了kprobes或陷阱处理，而不是dump_stack()所必需的。因此，如果只是使用dump_stack()，可能不需要这两个头文件。 所以，最小集可能是： ```c #include <linux/module.h> #include <linux/init.h> #include <linux/printk.h> ``` 但是，由于内核版本差异，如果上述头文件不行，可以尝试包含<linux/sched.h>（在旧内核中，dump_stack()可能在此头文件中声明）。 因此，我们可以建议用户根据内核版本选择合适的头文件，或者同时包含<linux/printk.h>和<linux/sched.h>以确保安全。 另外，在引用[4]的代码中，没有包含<linux/printk.h>，但是使用了printk()，而printk()通常也在<linux/printk.h>中声明。不过，<linux/module.h>可能已经包含了<linux/printk.h>，所以可能不需要显式包含。但为了明确使用dump_stack()，显式包含<linux/printk.h>是一个好习惯。 结论： 推荐包含： ```c #include <linux/module.h> #include <linux/init.h> #include <linux/printk.h> ``` 如果编译不通过，可以尝试增加： ```c #include <linux/sched.h> ``` 根据引用[2]和[4]，dump_stack()函数在内核中实现，因此上述头文件仅适用于内核模块编程，不适用于用户空间程序。 注意：用户空间程序不能使用dump_stack()，它是内核函数。用户空间程序可以使用backtrace()系列函数（在<execinfo.h>中）来获取堆栈信息。 因此，如果用户是在编写内核模块，则使用上述头文件；如果是在用户空间，则使用不同的方法。 根据用户的问题，他是在内核模块中使用，所以按照上述建议。</think>在 Linux 内核模块编程中，`dump_stack()` 函数所需的头文件如下： **核心头文件**： 1. `#include <linux/printk.h>` 这是**最直接**包含 `dump_stack()` 函数声明的头文件（适用于较新内核版本）[^2][^4]。 **常见组合**（根据实际使用场景）： ```c #include <linux/module.h> // 模块基础功能（必需） #include <linux/init.h> // 模块初始化和退出宏 #include <linux/printk.h> // dump_stack() 声明 ``` **其他可能相关的头文件**（根据具体上下文）： - `#include <linux/sched.h>`：在旧内核版本中可能包含此声明 - `#include <asm/traps.h>`：处理底层陷阱时使用（如引用示例）[^4] - `#include <linux/kprobes.h>`：动态内核调试场景（如引用示例）[^4] ### 使用示例 ```c #include <linux/module.h> #include <linux/init.h> #include <linux/printk.h> // 关键头文件 static int __init demo_init(void) { printk("开始堆栈追踪\n"); dump_stack(); // 打印内核调用栈 printk("追踪结束\n"); return 0; } module_init(demo_init); ``` ### 注意事项 1. **内核版本差异**： 在旧内核中（如 3.x 系列），`dump_stack()` 可能定义在 `<linux/sched.h>` 中，建议同时包含 `<linux/printk.h>` 和 `<linux/sched.h>` 确保兼容性。 2. **用户空间不适用**： 该函数仅在内核空间有效，用户空间程序需使用 `backtrace()`（需 `<execinfo.h>`）[^5]。 3. **调试局限性**： `dump_stack()` 可能因编译器优化（如尾调用优化）或符号表范围限制导致堆栈信息不完整[^2]。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值