【Linux】【开发】dump_stack导栈信息不准确问题浅析

原创 已于 2024-11-27 14:32:45 修改 · 1k 阅读 · 21 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#linux #dump_stack #导栈 #堆栈 #回溯 #inline #static

于 2024-11-12 09:01:03 首次发布

dump_stack导栈信息不准确问题浅析

简介

  • dump_stack函数是Linux内核开发调试时用于堆栈回溯的常用手段，但令人苦恼的是，有些情况下，堆栈回溯信息并不准确，打印出来的调用栈和实际的对不上，可能的情况及原因有很多种，本文只分析函数本身的因素。
  • 在调试过程中，发现有的static函数会导栈失败，有的static函数不会。static函数导致失败的时候，把static去掉就正常了。这说明不是static直接导致的导栈失败。本文将会通过实验来验证下，到底是什么因素导致的失败，以及规避的方法。

准备基础demo

基础程序如下

  • hello.c文件
#include<linux/module.h>  
#include<linux/kernel.h>  
#include<linux/init.h>

MODULE_LICENSE("GPL"); 

static int hello_init(void)    
{
	printk(KERN_ALERT "Hello World\n"); 
	return 0;
}
static void hello_exit(void)
{
	printk(KERN_ALERT "Goodbye World\n");
}

module_init(hello_init);
module_exit(hello_exit);
  • Makefile文件
obj-m := hello.o

KERNEL_DIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd) 

all:
	make -C $(KERNEL_DIR) M=$(PWD) modules
clean:
	make -C $(KERNEL_DIR) M=$(PWD) clean

编译命令

  • 直接make即可。

操作的命令

sudo insmod hello.ko    #加载模块
lsmod   #查看hello是否成功加载
dmesg   #查看ko执行的日志
sudo rmmod hello   #卸载模块

基础代码

代码改造

  • 将之前程序改造一下，在hello_init中调用一个普通的func函数：
void func(void)
{
    dump_stack();
}
static int hello_init(void)    
{
	printk(KERN_ALERT "Hello World\n"); 
	func();
    return 0;
}

看下导栈情况，正常的

  • 导栈如下：
[523017.373263] Call Trace:
[523017.373283]  dump_stack+0x66/0x90
[523017.373288]  ? func+0xa/0xa [hello]
[523017.373291]  hello_init+0x16/0x19 [hello]
[523017.373298]  ? do_one_initcall+0x46/0x1c3
[523017.373305]  ? free_unref_page_commit+0x9b/0x110
[523017.373309]  ? _cond_resched+0x15/0x30
[523017.373314]  ? kmem_cache_alloc_trace+0x15f/0x1e0
[523017.373318]  ? do_init_module+0x5a/0x210
[523017.373320]  ? load_module+0x2064/0x22a0
[523017.373324]  ? __do_sys_finit_module+0xa8/0x110
[523017.373326]  ? __do_sys_finit_module+0xa8/0x110
[523017.373329]  ? do_syscall_64+0x5f/0x190
[523017.373332]  ? async_page_fault+0x8/0x30
[523017.373336]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9

简单分析

  • 编译出ko之后，发现ko中有func这个符号：
[qxhgd@linux ~]$  readelf -a hello.ko | grep -i func
    27: 0000000000000000    10 FUNC    LOCAL  DEFAULT    4 func
    28: 000000000000000a    25 FUNC    LOCAL  DEFAULT    4 hello_init
    29: 0000000000000023    17 FUNC    LOCAL  DEFAULT    4 hello_exit
    32: 0000000000000023    17 FUNC    GLOBAL DEFAULT    4 cleanup_module
    34: 000000000000000a    25 FUNC    GLOBAL DEFAULT    4 init_module
  • 反汇编看下：
 objdump -D -S ./hello.ko > hello.txt

汇编代码如下：

void  func(void)
{
   0:	e8 00 00 00 00       	callq  5 <func+0x5>
    dump_stack();
   5:	e9 00 00 00 00       	jmpq   a <init_module>

000000000000000a <init_module>:
}

static int hello_init(void)    
{
   a:	e8 00 00 00 00       	callq  f <init_module+0x5>
	printk(KERN_ALERT "Hello World\n"); 
   f:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
  16:	e8 00 00 00 00       	callq  1b <init_module+0x11>
    dump_stack();
  1b:	e8 00 00 00 00       	callq  20 <init_module+0x16>
	func();
    return 0;
}

使用static函数

代码改造

  • 将之前程序改造一下，在hello_init中调用一个func函数：
static void func(void)
{
    dump_stack();
}
static int hello_init(void)    
{
	printk(KERN_ALERT "Hello World\n"); 
	func();
    return 0;
}

看下导栈情况，有点问题，func被省略了

  • 导栈如下：
[474765.242331] Call Trace:
[474765.258744]  dump_stack+0x66/0x90
[474765.262210]  ? 0xffffffffc0c4b000
[474765.262216]  hello_init+0x16/0x19 [hello]
[474765.262241]  ? do_one_initcall+0x46/0x1c3
[474765.262260]  ? free_unref_page_commit+0x9b/0x110
[474765.262270]  ? _cond_resched+0x15/0x30
[474765.262284]  ? kmem_cache_alloc_trace+0x15f/0x1e0
[474765.262292]  ? do_init_module+0x5a/0x210
[474765.262294]  ? load_module+0x2064/0x22a0
[474765.262298]  ? __do_sys_finit_module+0xa8/0x110
[474765.262299]  ? __do_sys_finit_module+0xa8/0x110
[474765.262302]  ? do_syscall_64+0x5f/0x190
[474765.262305]  ? async_page_fault+0x8/0x30
[474765.262308]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9

简单分析

  • 编译出ko之后，发现ko中并没有func这个符号：
    [qxhgd@linux ~]$ readelf -a hello.ko | grep -i func
    27: 0000000000000000 25 FUNC LOCAL DEFAULT 4 hello_init
    28: 0000000000000019 17 FUNC LOCAL DEFAULT 4 hello_exit
    31: 0000000000000019 17 FUNC GLOBAL DEFAULT 4 cleanup_module
    33: 0000000000000000 25 FUNC GLOBAL DEFAULT 4 init_module
  • 反汇编看下：
 objdump -D -S ./hello.ko > hello.txt

可以看到，static而非inline的func函数被内联了：

static int hello_init(void)    
{
   0:	e8 00 00 00 00       	callq  5 <init_module+0x5>
	printk(KERN_ALERT "Hello World\n"); 
   5:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
   c:	e8 00 00 00 00       	callq  11 <init_module+0x11>
    dump_stack();
  11:	e8 00 00 00 00       	callq  16 <init_module+0x16>
	func();
    return 0;
}

此处，当编译器对内联函数作展开处理时，会直接在调用处展开内联函数的代码，不再给 func() 函数本身生成单独的汇编代码。这是因为其它调用该函数的位置都作了内联展开，没必要再去生成。

使用noinline

继续改造

static void noinline func(void)
{
    dump_stack();
}

static int hello_init(void)    
{
	printk(KERN_ALERT "Hello World\n"); 
	func();
    return 0;
}

查看导栈信息，已经正常：

[475875.681135] Call Trace:
[475875.681147]  dump_stack+0x66/0x90
[475875.681162]  ? func+0xa/0xa [hello]
[475875.681164]  hello_init+0x16/0x19 [hello]
[475875.681172]  ? do_one_initcall+0x46/0x1c3
[475875.681179]  ? free_unref_page_commit+0x9b/0x110
[475875.681184]  ? _cond_resched+0x15/0x30
[475875.681189]  ? kmem_cache_alloc_trace+0x15f/0x1e0
[475875.681193]  ? do_init_module+0x5a/0x210
[475875.681194]  ? load_module+0x2064/0x22a0
[475875.681198]  ? __do_sys_finit_module+0xa8/0x110
[475875.681199]  ? __do_sys_finit_module+0xa8/0x110
[475875.681203]  ? do_syscall_64+0x5f/0x190
[475875.681205]  ? async_page_fault+0x8/0x30
[475875.681208]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9

简单分析

  • 查看符号表，其中有func这个符号：
[qxhgd@linux ~]$  readelf -a hello.ko | grep -i func
    27: 0000000000000000    10 FUNC    LOCAL  DEFAULT    4 func
    28: 000000000000000a    25 FUNC    LOCAL  DEFAULT    4 hello_init
    29: 0000000000000023    17 FUNC    LOCAL  DEFAULT    4 hello_exit
    32: 0000000000000023    17 FUNC    GLOBAL DEFAULT    4 cleanup_module
    34: 000000000000000a    25 FUNC    GLOBAL DEFAULT    4 init_module

-反汇编看下，

 objdump -D -S ./hello.ko > hello.txt

可以看到，func已经不再是内联了：

static void noinline func(void)
{
   0:	e8 00 00 00 00       	callq  5 <func+0x5>
    dump_stack();
   5:	e9 00 00 00 00       	jmpq   a <init_module>

000000000000000a <init_module>:
}

static int hello_init(void)    
{
   a:	e8 00 00 00 00       	callq  f <init_module+0x5>
	printk(KERN_ALERT "Hello World\n"); 
   f:	48 c7 c7 00 00 00 00 	mov    $0x0,%rdi
  16:	e8 00 00 00 00       	callq  1b <init_module+0x11>
	func();
  1b:	e8 e0 ff ff ff       	callq  0 <func>
    return 0;
}

小结

  • 造成dump_stack函数的原因，是因为gcc将部分static函数优化为inline函数了。如果函数没有使用static修饰，则可能不会被优化为inline函数。
  • 通过在函数中增加noinline修饰符，也可保证不被优化。
  • 另外，通过调整gcc的优化等级，应该也可以解决这个问题。

如本文对你有些许帮助，欢迎大佬支持我一下（点赞+收藏+关注、关注公众号等），您的支持是我持续创作的竭动力
支持我的方式

linux 应用程序 dump stack,内核中dump_stack()的实现，并在用户态模拟dump_stack()
weixin_35334000的博客
05-05 1114
内核中的dump_stack()获得内核中当前进程的栈回溯信息需要用到的最重要的三个内容就是：栈指针：sp寄存器，用来跟踪程序执行过程。返回地址：ra寄存器，用来获取函数的返回地址。程序计数器：epc，用于定位当前指令的位置。本文的内容都是基于mips体系架构的，如果你不搞mips，就只看个大致流程就可以了，不然可能会被某些内容误导。在ARM中，这三个寄存器分别为SP、LR和PC寄存器。dump_...
Linux内核的栈回溯dump_stack原理
gjioui123的博客
08-26 507
浅析ARMv8体系结构：Aarch64过程调用标准_aarch64-64-little-CSDN博客 (重磅原创)冬之焱: 谈谈Linux内核的栈回溯与妙用-腾讯云开发者社区-腾讯云 (tencent.com)
dump_stack分析与应用
wosiwozaiwhy的专栏
12-25 2418
一、dump_stack(堆栈转储）作用：主要用于内核调试，打印内核堆栈段信息。使用dump_stack在driver开发期间清晰查看内核中函数调用流程 二、使用前便已内核时：使用前，先在内核配置中把kernel debug选上： make menuconfig: kernel hacking--> kernel debug 三、arch/x86/kernel/dumpstack.c
linux show stack/dump_stack函数分析
陌上花开缓缓归以的博客
07-02 401
函数用于打印当前进程或指定进程的内核态堆栈信息。其核心功能是回溯函数调用栈，并打印出每个函数的地址。// 调用汇编函数回溯栈。是内核调试的重要工具。
Linux下的dump_stack
Android开发
12-01 955
当kernel出现错误时，会打印堆栈信息，我们可以根据信息追溯问题的来源，该函数实行如下 /** * dump_stack - dump the current task information and its stack trace * * Architectures can override this implementation by implementing its own. ...
【Linux内核调试-dump_stack】
cddchina的专栏
06-07 1537
Linux内核调试
dump_stack 实现分析
huifeidedabian的博客
04-25 559
1 .lib/dump_stack.c static void __dump_stack(void) { dump_stack_print_info(KERN_DEFAULT); show_stack(NULL, NULL); } 2 .arch/arm64/kernel/traps.c void show_stack(struct task_struct *tsk, unsigned long *sp) { dump_backtrace(NULL, tsk); barrier(); } dum
linux rcu浅析
kaka__55的博客
02-23 1928
rcu浅析
linux gmac驱动分析,以太网驱动流程浅析（一）-ifconfig主要流程
weixin_30440363的博客
05-13 2769
原标题：以太网驱动流程浅析(一)-ifconfig主要流程 作者简介： 大家好，我叫张昺华，中间那个字和“饼”字一个读音。2014年我毕业于广东省惠州学院，我从小酷爱理科，当看到陈莉君老师在《Linux内核之旅》上发的学生在课堂上用课本剧的方式来诠释技术时，想到了自己初中的时候老师就是这样锻炼我们的，很喜欢那样的学习氛围，自己大学时和小伙伴们一起创立了科技创新协会，目的就是可以一群人在研究技术，一...
linux 中断机制浅析
paomadi的专栏
03-27 4587
一、中断相关结构体 1.irq_desc中断描述符 struct irq_desc { #ifdef CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED struct irq_data irq_data; #else union { struct irq_data irq_data; //中断数据 struct { unsigned int irq;
Linux Perf 性能分析工具及火焰图浅析
didi_cloud的博客
12-05 1055
Perf Event 子系统Perf 是内置于 Linux 内核源码树中的性能剖析（profiling）工具。它基于事件采样的原理，以性能事件为基础，支持针对处理器相关性能指标与操作系统相关性能指标的性能剖析。可用于性能瓶颈的查找与热点代码的定位。本文将详细介绍 Linux Perf 的工作模式、Perf Events 的分类、Perf Tool 工具集以及火焰图的相关内容。下图展示了Perf的整...
ARM 架构 dump_stack 实现分析(1.0 具体实例)
李子的备忘录
11-15 3200
dump_stack也就是我们平时说的backtrace对分析，对异常或crash发生的时候，具有重要的意义   每种架构会有或多或少的区别，如现在linux kernel支持如下架构： alpha  avr32     c6x   frv    hexagon    m68k        mips     openrisc  powerpc  score  sparc  um  
dump_stack
liaokesen168的博客
10-21 560
linux内核驱动调试： dump_stack()堆栈打印。。。 待完善！！！！！！！！
dump_stack()
lyndon
08-10 1346
dump_stack() 能够提高我们分析代码的效率。
dump_stack( )
天使之翼
03-07 853
dump_stack()函数可以让其放置的函数的调用栈打印出来，对于定位问题很有帮助。
linux dump_stack 栈回溯原理
oqqYuJi12345678的博客
11-02 3098
linux arm架构下的栈回溯主要有两种方式，一种是基于fp栈帧寄存器的栈回溯，还有一种是unwind形式的栈回溯。 1 基于fp栈帧寄存器的栈回溯 在介绍栈回溯原理前，先贴一下arm的基本寄存器： 寄存器 含义 r0-r3 用作函数传参，例如函数A调用函数B，如果A需要向B传递参数，则将参数放到寄存器r0-r3中，如果参数个数大于4，则需要借用函数的栈空间。 r4-r11 变量寄存器，在函数中可以用来保存临时变量。 r9(SB) 静态基址寄存器。 r10(S
[小技巧] dump_stack()
闲云孤鹤
11-07 3303
本文转载至：http://jason-work-note.blogspot.jp/2012/03/dumpstack.html
Linux打印内核函数调用栈（dump_stack）
kunkliu的博客
04-26 6126
在Linux内核中提供了一个可以打印出内核调用堆栈的函数 dump_stack()该函数在我们调试内核的过程中可以打印出函数调用关系，该函数可以帮助我们进行内核调试，以及让我们了解内核的调用关系。该函数头文件为：#include <asm/ptrace.h>使用方式：直接在想要查看的函数中添加dump_stack();案例：随便写了一个模块test.c，test.c代码如下：    #include <linux/module.h>  &nbs
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]。
评论 3
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

花神庙码农

你的鼓励是我码字的最大动力!

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值