EDA365电子论坛网

标题: Linux内核设计与实现之内核调试 [打印本页]

---

作者: pulbieup    时间: 2021-3-9 09:42
标题: Linux内核设计与实现之内核调试

* z* ^. f! a) ^( h8 l( |% \! F
2 x# a( R( w" l) D; D内核调试的难点在于它不能像用户态程序调试那样打断点，随时暂停查看各个变量的状态。
# u% ?' H" Q8 J
也不能像用户态程序那样崩溃后迅速的重启，恢复初始状态。
) Z1 x) }7 I* E7 M: A( q


用户态程序和内核交互，用户态程序的各种状态，错误等可以由内核来捕获并显示。
5 h: @  r' ?0 t+ p
而内核是直接和硬件交互的，内核出错之后整个系统就无法正常运行了，所以要想熟练的进行内核调试，

/ J1 V* n2 N& u6 X& m8 c$ B首先要熟悉内核已经给我们提供的工具，然后实实在在的去做一些内核功能的开发，在开发的过程中不断熟悉内核代码，增加内核调试的经验。

% a; d8 O0 y% }

主要内容：

内核调试的难点
( w: _* A9 O( \2 H& {5 ^4 @2 F) Q内核调试的工具和方法
5 p" Y+ K% e. _( ]8 n总结
  u5 \* u' ?3 I/ m- r  C, B

1. 内核调试的难点
2 [, e- Y! K8 P, z内核调试的难点大致有以下几个：
3 ^6 m# ~( h/ W; O9 j8 e% y
5 \2 f2 @% r+ q: _重现bug困难 - 如果能够重现一个bug, 相当于成功了一半. (特别是有些bug和硬件相关, 执行几百万次之后才有一次错误)
调试风险比较大 - 稍有不慎, 即造成系统崩溃
定位bug的初始版本困难 - 内核版本更新很快, 很难确定bug是在那个版本开始出现的
1 u# o* J3 _2 S' m2 O6 Z3 l6 f
/ [+ h4 l( v8 e: \, V
2. 内核调试的工具和方法
8 ~/ \. k8 i) M7 r$ j/ p内核调试虽然困难, 但同时也极具挑战性, 如果能够解决一个困扰大家多时的内核bug, 那将会给自己带来极大的成就感.

而且, 随着内核的不断发展, 内核调试的手段和方法也在不断进步, 下面是书中提到的一些常用的调试手段.
& }$ j3 `% t& ?9 j  \: a0 E+ r. I

0 [- L3 L. h) X, |5 T  T" ^. w6 @* k
$ Y& M7 {* b: I0 t( e  A  a, `2.1 输出 LOG
+ z, p9 M9 h$ ^9 i" M输出LOG不光是内核调试, 即使是在用户态程序的调试中, 也是经常使用的一个调试手段.
9 ~8 `! R' K4 Y1 \- n- i: g. H& [
% \$ r) l  C$ C+ O, e通过在可疑的代码周围加上一些LOG输出, 可以准确的了解bug发生前后的一些重要信息.
) h8 ^; y5 Z4 [; j
: n, a3 P2 D4 ?1 f* x9 o2 k$ ^

2.1.1 LOG等级
linux内核中输出LOG的函数是 printk (语法和printf几乎雷同, 唯一的区别是printk可以指定日志级别)

" L! S1 v5 D! V" L& Jprintk之所以好用, 就在与它随时都可以被调用, 没有任何限制条件.

0 z) R* g) R. {5 E/ j" j8 c" j# `5 Z  Sprintk的输出日志级别如下:

等级	描述
KERN_EMERG	一个紧急情况
KERN_ALERT	一个需要立即被注意到的错误
KERN_CRIT	一个临界情况
KERN_ERR	一个错误
KERN_WARNING	一个警告
KERN_NOTICE	一个普通的, 不过也有可能需要注意的情况
KERN_INFO	一条非正式的消息
KERN_DEBUG	一条调试信息--一般是冗余信息

" B7 z4 d3 K3 ?& }( Y* d% J. D/ w
$ ^5 t! y7 Z& C. `# {/ m
输出示例:

# g; z0 x- ^. {, P3 W; m7 |8 sprintk(KERN_WARNING "This is a warning!\n");
9 l6 p: }5 `/ E6 dprintk(KERN_DEBUG "This is a debug notice!\n");
: ]0 S4 X+ Z% q
. V! Z) j5 J# y- Y0 {  t* b
" D5 D/ b* ^4 n. R0 _$ ]+ n9 t$ U2.1.2 LOG记录
标准linux系统上, printk 输出log之后, 由用户空间的守护进程klogd从缓冲区中读取内核消息, 然后再通过syslogd守护进程将它们保存在系统日志文件中.
6 [; r- j. U. n; F" p
. }: M5 }5 ~3 V  w9 G! ~syslogd 将接受到的所有内核消息添加到一个文件中, 该文件默认为: /var/log/dmesg (系统Centos6.4 x86_64)
$ Y8 B: v1 K( m2 p8 N- o  A


PS. 上篇博客中的内核模块的输出LOG, 都可以在 /var/log/dmesg 中看到

: i$ @( Q* H/ I5 t: q; o) t' q
$ B# [. j% k; |% p
/ F7 W5 m# K' v* |# v: @2.2 oops
0 c: Q* z/ D. O+ a( s3 Ooopss是个拟声词, 类似 "哎哟" 的意思. 它是内核通知用户有不幸发生的最常用方式.
; ^% G" N# i: c8 Q( y8 r
触发一个oops很简单, 其实只要在上篇博客中的那些内核模块示例中随便找一个, 里面加上一段给未初始化的指针赋值的代码, 就能触发一个oops

) B5 A+ Q8 ^9 p' o# s7 ]

* s, j5 S  R& W' ]1 |# B) g5 w+ X! yoops中包含错误发生时的一些重要信息(比如, 寄存器上下文和回溯线索), 对调试bug很有帮助!

- O, @8 b. l* v! V0 }; a
+ N. z4 I9 V3 @
调试内核时, 还可以开启内核编译参数中的各种和内核调试相关的选项, 那样还可以给我们提供内核崩溃时的一些额外信息.



2.3 主动触发bug

调试中有时将某些情况下标记为bug, 执行到这些情况时, 提供断言并输出信息.

6 U- }, i4 T- |. n/ ]+ i# \BUG 和 BUG_ON 就是2个可以主动触发oops的内核调用.

0 C6 t; _- j/ Q" D2 Q
; h% E& v( o& ~: f) t9 h' M) i
+ B' F1 W- F9 E" x# U在不应该被执行到的地方使用 BUG 或者 BUG_ON 来捕获.

3 ~1 z; M/ y) ~, i7 w$ M0 _2 c比如:
! n) X3 B! r2 {7 f, H6 l9 O
if (bad_thing)
    BUG();
// 或者
! k' y. [$ f. E$ wBUG_ON(bad_thing);
. w" k7 @: a1 f5 |( D& R! Q$ D9 d, p

如果想要触发更为严重的错误, 可以使用 panic() 函数
- W# b2 y0 q) ~- d. F$ s" g
, E: ?) _8 W4 a; C比如:
9 H! t8 H* D. D4 `
: e0 a' b2 d( h- l/ vif (terrible_thing)
    panic("terrible thing is %ld\n", terrible_thing);


此外, 还有dump_stack 函数可以打印寄存器上下文和回溯信息.

. b4 a' I; k7 M6 ^! ~, Z# h比如:

. e4 H% q! A/ I. F3 Nif (!debug_check) {
    printk(KERN_DEBUG "provide some information...\n");
    dump_statck();
0 [8 F" C! i3 e, x$ ^) r}

8 }- n  d: [( b
2.4 神奇的系统请求键
$ a, |. ]  o! i
这个系统请求键之所以神奇, 在于它可以在一个快挂了的系统上输出一些有用的信息.

这个按键一般就是标准键盘上的 [SysRq] 键 (就在 F12 键右边, 其实就是windows中截整个屏幕的按键)

单独按那个键相当于截屏, 按住 ALT + [SysRq] = [SysRq]的功能



启用这个键的功能有2个方法:

* E6 R7 V1 W9 x( F% c& `. {

• 开启内核编译选项 : CONFIG_MAGIC_SYSRQ
• 动态启用: echo 1 > /proc/sys/kernel/sysrq
  ; ^4 Q# N+ Q" g3 ^& i  Q8 h& {

支持 SysRq 的命令如下: (注意要在控制台界面下使用这个键, 比如通过 ALT+CTRL+F2 进入一个控制台界面)
+ A  O- j$ ~3 q+ K5 @( N6 o$ ?2 _' @

主要命令	描述
SysRq-b	重新启动机器
SysRq-e	向init以外的所有进程发送SIGTERM信号
SysRq-h	在控制台显示SysRq的帮助信息
SysRq-i	向init以外的所有进程发送SIGKILL信号
SysRq-k	安全访问键:杀死这个控制台上的所有程序
SysRq-l	向包括init的所有进程发送SIGKILL信号
SysRq-m	把内存信息输出到控制台
SysRq-o	关闭机器
SysRq-p	把寄存器信息输出到控制台
SysRq-r	关闭键盘原始模式
SysRq-s	把所有已安装文件系统都刷新到磁盘
SysRq-t	把任务信息输出到控制台
SysRq-u	卸载所有已加载文件系统

! o4 S, v% N  d. a
3 ]' A0 Q! D' q. Q
9 h( a1 b) p) o! m5 ]2 ~2.5 内核调试器 gdb和kgdb

linux内核的调试器可以使用 gdb或者kgdb, 配置比较麻烦, 准备实际用调试的时候再去试试效果如何..



2.6 探测系统
$ j! }9 L/ M& p/ W6 m
下面一些方法是在修改内核后, 用来试探内核反应的小技巧.
% E" G- \* J) ]6 N+ [3 h* ~: `
' e. u  P) M7 l) h
, s0 h' a2 H$ B# D- c2.6.1 用UID控制内核执行
! c" ~' ~, N: O$ Y* d7 W
3 C8 }0 a, h) ]" }, `5 s: |比如在内核中加入了新的特性, 为了测试特性, 可以用UID来控制内核是否执行新特性.

& [) f- z8 N$ Y( f) Y: }7 Lif (current->uid != 7777) {
    /* 原先的代码 */
} else {
" Z8 h9 ]( p" X9 U" o) p   /* 新的特性 */
}

2 d" z3 g! p0 F; j9 U
2.6.2 用条件变量控制内核执行

也可以设置一些条件变量来控制内核是否执行某段代码.

条件变量可以像上篇博客中那样, 设置在 sys 文件系统的某个文件中. 当文件中的值变化时, 通知内核执行相应的代码.
* p* B9 T) b+ H2 T. u0 s& q
' ^5 w" B% v/ J! b' ?* y
& ~! [4 Y7 h% @7 Z
" S, j( ?# i: z- f1 {( f' P( e2.6.3 使用统计量观察内核执行某段代码的频率

$ M6 k$ Z0 ~- z& i实现思路就是在内核中的设置一个全局变量, 比如 my_count, 当内核执行到某段代码时, 给 my_count + 1 就行.
! U4 H" ]# {. F# W: m
同时还要将 my_count 打印出来(可以用printk), 便于随时查看它的值.



2.6.4 控制内核执行某段代码的频率

有时侯, 我们需要在内核发生错误时打印错误相关的信息, 如果这个错误不会导致内核崩溃, 并且这个错误每秒会发生几百次甚至更多.

  E$ U4 i1 }' x3 S/ j9 B8 B那么, 用printk输出的信息会非常多, 给系统造成额外的负担.

, t3 }1 l. G3 l9 i2 c. A9 \* c这时, 我们就需要想办法控制错误输出的频率, 有2种方法:
% Z# y# I; h2 ~. A! h% r
方法1: 隔一段时间才输出一次错误
  M" R1 ?- q: T& i; H5 r& c
1 Z( U$ K" T( P& x, sstatic unsigned long prev_jiffy = jiffies;  /* 频率限制 */

if (time_after(jiffies, prev_jiffy + 2*HZ)) {  /* 输出间隔至少 2HZ */
    prev_jiffy = jiffies;
$ |' B) Q1 @, U5 `& z    printk(KERN_ERR "错误信息....\n");
}
# s" ?% V" P7 r- s3 w2 m8 z
/ l- b1 v! A7 t0 A
7 e- P* }3 G9 [; T( v* M方法2: 输出 N 次之后, 不再输出(N是正整数)

static unsigned long limit = 0;

$ _$ a6 r0 a3 {' o0 Xif (limit < 5) { /* 输出5次错误信息后就不再输出 */
& [  o: Z. H$ t    limit++;
6 i* ~+ h9 _2 c7 U    printk(KERN_ERR "错误信息....\n");
: h9 d% s( A' S& X) Q}
7 h- O/ {' K9 |: s
3 ?. G1 U8 d0 m" m; w3 |. D
' j9 X, c/ H% L/ R2 i
. O1 y, l! h# f3 R2.7 二分法查找bug发生的最初内核版本
( H7 g# d; T2 A: Q5 u, w
在内核发生了bug之后, 如果能够知道是bug从哪个内核版本开始出现的, 那对修正这个bug会有很大的帮助.

由于内核代码非常庞大, 即使用二分查找法, 手工去找哪个版本开始出现bug的话, 仍然是非常耗时和繁琐的.
, W+ x6 j$ _. {* N4 o& O
- x- N( d5 H4 f  f5 w

& X7 @9 ^. f. ~, g' T& L5 @好在 Git 给我们提供了一个非常有用的二分搜索机制.

  l6 H2 b6 C! y# Vgit bisect start  # 开始二分搜索
% k. {& c# d1 }2 Z! r& ^+ P% _git bisect bad <bad_revision> # 指定一个bug出现的内核版本号
git bisect good <good_revision> # 指定一个没有bug的内核版本号, 此时git会检测2个版本直接的隐患
0 q+ o+ B6 i7 {# A2 u- X! W% w
# 根据结果再次设置 bad 和 good 的版本号, 缩小Git检索范围, 直至找到可疑之处为止.
3 _: c1 i( b9 e5 C$ `  W7 A

7 Q6 H5 @/ K# Q" L4 S& o
2.8 社区

当你在调试bug时用尽了一切手段仍然无济于事时, 可以考虑求助linux社区, 求助时注意一定要描述清楚bug的状况.
3 A! G3 ]8 Q9 M+ v/ W
& p4 D( ^# C; t2 t2 W(可以参考一下别人汇报bug的格式)

% Y; k9 P: Z* m4 w9 @- Z
+ K0 }7 ?* h+ `6 c, H# C

3. 总结

  Z( y* c9 m9 V, y* p3 y1 L2 Blinux内核调试必须要依靠大量的实践来掌握, 仅仅靠上面介绍的一些技巧还远远不够, 只有实实在在的去阅读内核代码, 实实在在的去修正一个个bug, 才算真正掌握内核, 真正了解内核.
! f5 |4 Y1 `( J, z
多看看之前linux内核bug的修正案例, 也是个不错的积累经验的方法.
5 v2 Z) C8 R0 X) |' i


6 K' B, B  N6 }  r1 m3 I$ S) HPS.
6 T+ \+ l0 J9 N  B
6 [2 I7 a! u( N! x6 i0 w对于初学者来说, 在真机上做内核开发动辄导致机器崩溃(panic), 非常麻烦. 现在的虚拟机这么强大, 建议都在虚拟机上测试linux内核修改的效果.
5 M- h* p: L" R0 q
3 G3 s4 z$ `/ P% J; ~我之前的关于<<Linux内核设计与实现>>笔记的博客中的代码都是在虚拟机上运行测试的.
  q- U/ g% d9 a' O) \

---

作者: CCxiaom    时间: 2021-3-9 10:44
Linux内核设计与实现之内核调试

---

欢迎光临 EDA365电子论坛网 (https://bbs.eda365.com/)

Powered by Discuz! X3.2