内核调试trace的方法

最新推荐文章于 2025-07-08 16:46:52 发布
原创 最新推荐文章于 2025-07-08 16:46:52 发布 · 2.5k 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#Kernel #ftrace #perf

本文介绍了一系列用于内核调试和性能分析的方法和技术，包括Ftrace和Perf工具的使用，以及如何通过命令查看中断、软中断等信息。

Ftrace目录

/sys/kernel/debug/tracing/events/timer/tick_stop/

使用filer过滤输出

TRACE代码目录

kernel-rt-3.10.0-thinkcloud/include/trace/events

Perf使用说明目录

kernel-rt-3.10.0-thinkcloud/tools/perf/Documentation

./perf list查看哪些event可以加入

 ./perf record -e sched:sched_switch -g -C 13-16 sleep 10

 ./perf report -g --no-children --stdio

其他内核调试命令

查看Local interrupt timer中断变化

watch -n1 -d "cat /proc/interrupts |egrep 'LOC|CPU'"

查看软中断

cat /proc/softirqs

查看任务及堆栈细节状态

echo 't' > /proc/sysrq-trigger

查看任务队列

cat /proc/sched_debug

查看每核定时器

cat /proc/timer_list

Ftrace目录

/sys/kernel/debug/tracing/events/timer/tick_stop/

使用filer过滤输出

Perf工具

perf已经放在180环境的node4上/root目录

./perf record -C 13,14,15,16

./perf report

6、内核调试方法与 printk 调试工具详解
e1f2g的博客
08-04 4
本文详细介绍了Linux内核调试的多种方法和技术，包括动态分析、静态分析、代码覆盖分析、监控和跟踪工具以及事后分析等。重点讲解了printk调试工具的使用方法及其日志级别的设置，并提供了高效的内核源代码浏览技巧和调试工具的选择策略。通过这些方法，开发者可以在不同场景下灵活运用合适的调试技术，快速定位并解决内核中的问题。
Linux内核Call Trace调试分析方法
da_xiang的博客
01-15 3504
讲述了Call Trace 的调试方法
linux调度器（十）——调度器/proc信息解读
热门推荐
阿罗
02-06 2万+
注下面的时间或时刻都是从rq->clock中获得的，而这个值是由update_rq_clock底层cpu来更新的。并且很多信息是需要内核配置CONFIG_SCHEDSTATS才有。 /proc//sched $cat /proc/28733/sched     cpu_test (28733, #threads: 1) --------------------------
FTRACE内核实现浅析
qq_17045267的博客
07-08 1112
本文分析了Linux内核ftrace子系统中trampoline（蹦床）机制的具体实现原理。首先介绍了ftrace静态跟踪（tracepoint）和动态跟踪的基本原理，重点阐述了编译器如何通过插入call __fentry__指令实现函数跟踪，以及内核如何将其替换为nop指令以降低开销。然后详细解析了trampoline的核心实现ftrace_regs_caller汇编代码，说明其如何通过保存寄存器状态、准备参数并跳转到真正的处理函数。文章还解释了trampoline在支持多ftrace_ops时的处理机制
一文叫你使用trace查看函数调用关系|分析Linux性能
youzhangjing_的博客
12-05 1607
抓取函数调用流程关系抓取函数耗时抓取代码片耗时抓取函数里每个子函数时间戳抓取事件信息trace是内核自带的工具，相比于perf工具，trace只管抓trace数据并没有分析，perf在trace数据分析方面做出了很多成果。 但是我们现在就想看一下底层多调用关系，所以使用trace抓一下数据是非常有必要的，还可以分析一下驱动性能。因为trace工具是内核自带的，所以我们配置一下内核就可以使用了：trace 通过 debugfs 向用户态提供了访问接口，所以还需要将 debugfs 编译进内核。激活对 debu
linux kernel debug 之 CallTrace
大张
07-15 1万+
这篇文章是基于上次UWB(WUSB) wireless debug 的一个问题，然后引申出来的一个话题，对kenel有一定理解的同学可能会有一定的帮助。 --其实这个问题，个人认为，这个个CallTrace会一起down机，cpuhold的等问题，还是一个很大的问题。不过从一般意义上来讲，他是个warning我们可以不用管他。但谁让自己是做技术的呢，没办法，眼里容不得沙子。来吧干货。 1.  
Linux内核增加一个trace
weixin_38878510的博客
11-02 1798
Linux内核增加一个trace event 本内核版本是Linux-4.9.37，参考drivers/usb/dwc3/下的代码实现。 首先定义两个文件：trace.h和trace.c。 trace.h如下：定义一个事件类以及一个事件，最后包含头文件<trace/define_trace.h>。 #undef TRACE_SYSTEM #define TRACE_SYSTEM mj #if !defined(__MJ_TRACE_H) || defined(TRACE_HEADER_MULT
【Linux内核开发】调试方法框架全解析：从准备工作到高级工具的应用与优化
05-04
②提升对内核代码的理解，掌握内核调试的常用工具和方法；③通过实际案例和具体技术手段，提高内核开发的效率和稳定性。; 其他说明：本文不仅提供了理论知识，还结合了大量实际案例和具体操作步骤，旨在帮助读者全面...
【Linux内核开发】调试方法框架全解析：从准备工作到高级工具的应用与展望
05-04
接着详细解析了内核调试配置选项，如Magic SysRq key、Kernel debugging等，以及调试原子操作的设置；随后阐述了BUG()和BUG_ON()宏、dump_stack()函数、printk()函数的使用方法及其优缺点；最后介绍了procfs、sysfs...
Linux内核的经典调试方式
GitHub_miao的博客
12-20 1308
Linux内核调试和跟踪是一项复杂而强大的任务，需要深入的知识和经验。本文介绍了一系列经典的Linux内核调试和跟踪方式，包括使用 printk 记录日志、使用 gdb 进行调试、使用 Kdump 分析崩溃以及使用 BPF、Tracepoint、kprobes 和 ftrace 进行高级跟踪和分析。通过掌握这些工具和技巧，可以更好地理解和解决内核问题，提高系统的可靠性和性能，从而更好地应对复杂的Linux内核挑战。无论是内核开发人员还是系统管理员，这些技能都可以对工作产生积极的影响。
【ubuntu】linux内核模块call trace
HAICHANG1105的博客
07-05 823
【ubuntu】linux内核模块call trace
Linux内核中断trace机制log解析工具
08-14
用于将通过cat /sys/kernel/debug/tracing/trace命令获取的log文件，进行解析，和统计，分类：哪一号中断，在哪一号CPU上运行，总共运行时间多久，最大单次处理时间，最小单次处理时间，平均处理时间，相同中断发生在同一个CPU上面的最小间隔等。
Kernel源码笔记之Trace
苟浩的博客
03-01 1141
Ftrace // kernel/trace/trace.c // 注册一个tracer int __init register_tracer(struct tracer *type) { struct tracer *t; int ret = 0; // tracer名不能为空 if (!type->name) { pr_info("Tracer must have a name\n"); return -1; } // 名字长度不能超过MAX_TRACER_S
Linux内核调试方法总结之Call Trace
zmjames2000 Just record
03-11 8750
come from :https://www.cnblogs.com/justin-y-lin/p/5424488.html 内核态call trace 内核态有三种出错情况，分别是bug, oops和panic。 bug属于轻微错误，比如在spin_lock期间调用了sleep，导致潜在的死锁问题，等等。 oops代表某一用户进程出现错误，需要杀死用户进程。这时如果用户进程占用了某些信...
trace-event
本末实验室
12-24 906
接下来学习 trace_event 的工作原理和使用方法，希望未来能积累足够多的使用案例
linux内核bug问题排查过程详细报告
星.云计算
12-16 4171
Linux Kernel BUG:soft lockup CPU#1 stuck分析 1.线上内核bug日志 kernel: Deltaway too big! 18428729675200069867 ts=18446743954022816244 write stamp =18014278822746377 kernel:------------[ cut here ]---------...
内核trace框架
qq_42584874的博客
03-14 3897
Linux内核trace ​ 从广义上讲，linux中的跟踪系统由三层组成：前端、跟踪框架和事件源 ​ 事件源是跟踪数据的来源，跟踪框架运行在负责数据收集、计数的内核中，如果它支持内核编程跟踪程序（例如：eBPF），它还以有效的方式执行聚合、汇总和统计。跟踪前端工具提供了与跟踪框架通信的用户界面，使用后处理跟踪器（如果有）进行统计、汇总和聚合采样，并向最终用户进行结果可视化。 术语 性能分析：性能分析的目的是为了获取跟踪事件的样本 跟踪：跟踪记录所有的trace事件 探针：动态或者静态代码中的一种插装
Linux Kernel 使用Trace event查看log的方法步骤总结
A797276的博客
11-02 3299
调用trace event 看kernel log： 1. mount mkdir data/debugfs mount -t debugfs debugfs /data/debugfs 2.选择你要的tracer 例如： #cat current_tracer #cat available_treacers #echo blk > current_tracer 3.可以打开关闭你要追踪的LOG： #echo 1 > tracing_on // 打开跟踪 # ech
Trace Cache（Intel P4 CPU）
Leo ICer的博客
04-28 632
在P4处理器中，解码后的uop被存储在Trace Cache中。 Trace Cache 和 一般Cache区别： 在一般的Cache中，指令的存储顺序和内存中的指令顺序是一样的，而Trace Cache中的指令顺序是指令的执行顺序，而不是指令的地址顺序。 下面这个程序中，包含有跳转指令： load jmp T1;跳转到T1处 store ... T1: xor 指令在普通cache上存放的位置根据程序地址决定，指令这样存储： 而在Trace Cache中，指令的存储格式如下：
内核快速调试方法
最新发布
08-29
<think> 我们刚刚讨论了`dump_stack()`的使用方法，现在用户的新需求是查找内核快速调试的方法。根据用户提供的参考引用，我们可以总结出以下几种内核快速调试方法： 1. printk：最基础的调试方法，通过打印信息到内核日志 2. dump_stack：打印调用堆栈，用于追踪函数调用路径 3. OOPS消息分析：当内核发生致命错误时，会自动打印OOPS消息，其中包含寄存器状态和调用堆栈 4. kprobe：动态地在内核函数的特定位置插入断点，用于收集调试信息 5. ftrace：内核内置的跟踪工具，可以跟踪函数调用、中断开关等事件 6. Systemtap：强大的脚本工具，可以动态地监控和跟踪运行中的内核 7. kgdb/kdb：内核级别的调试器，支持远程调试和单步执行 我们将重点介绍几种快速、无需复杂配置的方法（printk, dump_stack, OOPS分析, ftrace基础用法），因为用户强调“快速调试”。 ### 一、最快速调试方法：`printk` 与 `dump_stack` #### 1. **printk** - 内核日志输出 ```c // 在需要调试的位置插入 printk(KERN_DEBUG "debug: variable x=%d\n", x); ``` - **查看方式**：`dmesg` 或 `tail -f /var/log/kern.log` - **优先级**：从 `KERN_EMERG`(0) 到 `KERN_DEBUG`(7)，通过 `/proc/sys/kernel/printk` 控制输出级别[^1] #### 2. **dump_stack** - 打印调用堆栈 ```c dump_stack(); // 直接插入代码中 ``` - **输出示例**： ```log [ 12.345678] Call Trace: [ 12.345679] [<ffffffff8107a04a>] dump_stack+0x46/0x58 [ 12.345681] [<ffffffff81234567>] my_debug_function+0x23/0x5a ``` - **作用**：立即输出当前函数调用链，无需崩溃触发[^1] ### 二、崩溃现场分析：OOPS 消息 当内核遇到无法处理的错误时（如空指针解引用），会打印 **OOPS 消息**，其中包含： - 错误类型（如“Unable to handle kernel NULL pointer dereference”） - 发生错误的CPU编号 - 寄存器状态 - 调用堆栈（与`dump_stack`类似） #### 分析步骤： 1. **定位出错指令地址**： ```log PC is at my_function+0x1a/0x30 ``` - `0x1a`：出错指令在函数内的偏移 - `0x30`：函数总长度 2. **反汇编定位代码行**： ```bash arm-linux-gnueabi-objdump -d vmlinux | grep -A 20 "my_function:" ``` 然后查找偏移量 `0x1a` 对应的指令[^3] ### 三、动态追踪：ftrace `ftrace` 是内核内置的低开销跟踪工具，无需重新编译内核。 #### 快速使用示例： 1. **启用函数跟踪**： ```bash cd /sys/kernel/debug/tracing echo function > current_tracer echo 1 > tracing_on # 执行待调试操作 echo 0 > tracing_on cat trace > /tmp/trace.log ``` 2. **只跟踪特定函数**： ```bash echo my_debug_function > set_ftrace_filter ``` 3. **输出解析**： ```log # tracer: function # # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | myapp-1234 [001] 456.789012: my_debug_function <-caller_function ``` - 显示函数调用关系及时间戳[^1] ### 四、调试方法对比表 | 方法 | 使用场景 | 速度 | 复杂度 | 需重启 | |---------------|------------------------------|--------|--------|--------| | `printk` | 打印变量值、流程标志 | ★★★ | ★ | 需要 | | `dump_stack` | 函数调用路径追踪 | ★★★ | ★ | 需要 | | OOPS分析 | 崩溃现场分析 | ★★ | ★★ | 不需要 | | ftrace | 动态函数调用追踪 | ★★ | ★★ | 不需要 | | kprobe | 在任意函数插入断点收集数据 | ★ | ★★★ | 不需要 | > **注**：速度评级（★越多越快）；复杂度评级（★越多越简单） ### 五、快速调试选择建议 1. **逻辑错误排查** → `printk` + `dump_stack` 2. **崩溃问题** → 分析自动生成的 OOPS 消息 3. **性能问题/并发竞争** → `ftrace` 或 `kprobe` §§相关问题§§ 1. 如何配置 `ftrace` 来跟踪内核模块中的函数？ 2. 当系统因 `printk` 过多而变慢时，有哪些优化方法？ 3. 如何利用 `kprobe` 实现内核函数的动态断点？ [^1]: [Linux内核的经典调试方式](http://blog.youkuaiyun.com/itsenlin/article/details/43205983) [^2]: [linux内核调试方法](https://example.link2) [^3]: [内核调试的几种方法](https://example.link3) </think> ### 内核快速调试方法指南 以下是内核开发中最实用的快速调试技巧，按优先级排序（从最快捷到进阶）： --- #### 1. **printk + dmesg 组合**（最基础高效） ```c // 在需要调试的位置插入 printk(KERN_DEBUG "Debug: var_x=%d, addr=%p\n", var_x, ptr); ``` - **查看输出**： ```bash dmesg -wH | grep "Debug:" # 实时跟踪带标记的日志 ``` - **优势**：零配置成本，适用于所有内核版本[^1] - **技巧**： - 使用 `KERN_DEBUG` 级别避免刷屏 - 插入函数边界标记：`printk("---- %s ENTER ----\n", __func__);` --- #### 2. **dump_stack() 动态追踪**（定位调用路径） ```c if (unlikely(error_condition)) { printk(KERN_ALERT "Error detected!\n"); dump_stack(); // 打印当前调用栈 } ``` - **输出示例**： ``` [ 123.456] Call Trace: [ 123.457] [<ffffffff812a8e04>] do_syscall_64+0x34/0x80 [ 123.458] [<ffffffff8100116a>] setup_something+0x2a/0xc0 ``` - **解析技巧**： ```bash cat /proc/kallsyms | grep ffffffff8100116a # 解析地址对应函数名 ``` 输出：`ffffffff8100116a T setup_something`[^2] --- #### 3. **OOPS 消息自动分析**（崩溃现场） 当内核崩溃时自动触发： 1. 保存 `/var/log/kern.log` 中的 OOPS 消息 2. **关键信息定位**： ``` PC is at snd_soc_dai_set_sysclk+0x10/0x84 ``` - `snd_soc_dai_set_sysclk`：崩溃函数 - `+0x10`：函数内偏移量 - `0x84`：函数总长度 3. **反汇编定位代码行**： ```bash objdump -d vmlinux | grep -A 20 "snd_soc_dai_set_sysclk" ``` 查找 `0x10` 偏移处的指令[^3] --- #### 4. **ftrace 动态跟踪**（无需重启） ```bash # 启用函数跟踪 echo function > /sys/kernel/debug/tracing/current_tracer echo 1 > /sys/kernel/debug/tracing/tracing_on # 过滤特定函数 echo "my_*" > set_ftrace_filter # 捕获数据 cat trace > /tmp/debug.log ``` - **优势**：实时跟踪函数调用关系，性能开销低[^1] - **输出解析**： ``` my_driver-152 [000] ...1 123.456789: my_function <-caller_function ``` --- #### 5. **kprobe 动态插桩**（高级调试） ```c #include <linux/kprobes.h> static struct kprobe kp = { .symbol_name = "target_function", }; static int handler_pre(struct kprobe *p, struct pt_regs *regs) { printk("Enter %s, arg0=0x%lx\n", p->symbol_name, regs->di); return 0; } // 模块初始化中注册 register_kprobe(&kp); ``` - **作用**：在任意函数入口插入调试逻辑 - **优势**：无需修改目标函数代码[^1] --- ### 调试方法对比表 | 方法 | 准备时间 | 实时性 | 适用场景 | |---------------|----------|--------|---------------------------| | printk | <1分钟 | 中 | 变量检查、流程跟踪 | | dump_stack | <1分钟 | 高 | 函数调用路径分析 | | OOPS分析 | 5分钟 | 事后 | 内核崩溃现场还原 | | ftrace | 3分钟 | 高 | 函数调用关系/耗时分析 | | kprobe | 10分钟 | 高 | 第三方函数参数监控 | > **黄金法则**：80%的问题可通过 `printk + dump_stack` 解决；复杂问题用 `ftrace`；崩溃分析首选 OOPS。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值