用户故事 | 用好动态调试，助力课程学习
下载APP
关闭
渠道合作
推荐作者
用户故事 | 用好动态调试，助力课程学习
2021-12-17 leveryd 来自北京
《操作系统实战45讲》
课程介绍
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="1142" height="640"><rect fill-opacity="0"/></svg>)
讲述：正霖
时长10:32大小9.62M
你好，我是 leveryd。
先做个自我介绍，我在网络安全行业从事技术工作，目前在负责安全产品的研发工作，工作六年。
虽然在研发工作中，我们通常是遇到什么问题就去查，边查边学。虽然这样的学习方式能快速解决问题，但有时候这种方法也不灵，比方说学习语义分析时，就必须要把词法分析、语法分析先学了，一通搜索、查阅、汇总和学习，回头一看，需要花费的时间和精力还是不少的。
显然，只靠自己在网上搜索，学到的常常是零零散散，效率太低。尤其是和工作的关联程度很高的必修知识，我觉得不太适合边查边学，更需要系统学习。结合自己的工作需要，今年年初的时候，我给自己安排了近期学习计划，定下了相应的学习的优先级。
其中，补充操作系统的专业知识就是高优先级的一项。近期学习《操作系统实战 45 讲》的过程中，我也跟着课程内容开始动手实践，还在课程群里分享了自己的调试经验。接到 LMOS 老师的邀请，今天我就和你聊聊我是怎样学习这门课程，以及我是如何调试课程代码的。
我是怎么学习《操作系统实战 45 讲》的
根据我的学习需求，我给自己立下了两个学习目标：
第一，理解第十三课的代码：第十三课之前的内容包括了整个机器初始化过程；
第二，理解第二十六课的代码：比第十三课内容多了“内存”和“进程”。
就目前我自己的学习经验来看，“内核实验”比较复杂。这主要是因为内核涉及的知识较多，比如 C 语言、汇编、硬件知识；而且这方面内容比较底层，某些概念我们平时接触得比较少，比如汇编层面的函数调用细节。
另外，部分算法乍一看确实有点难理解，比如第二十五课中进程的切换是利用“栈上的函数返回地址”，而“返回地址”包括初始化和后面被进程调度器更新这两种场景。我们需要弄清楚这两个场景都是怎么更新的，才能更好理解进程是如何切换运行的。
Cosmos 调试思路
因为刚才说的这些原因，当我们遇到疑问时，往往无法从网络上直接搜到答案。这个时候，就可以通过调试来辅助我们分析问题。
接下来，我就说一说我是怎么调试课程代码的，后面还会再分享一下我通过动态调试解决疑问的例子。
虽然我们可以在代码中打印日志，但这种方式效率不高，因为每次都需要编写代码、重新编译运行。我更喜欢用 GDB 和 QEMU 动态调试 Cosmos。
结合下图中我们可以看到：使用 GDB 在 Cosmos 内核函数下了断点，并且断点生效。如果我想观察 copy_pages_data 的逻辑，就只需要在单步调试过程中观察内存的变化，这样就能知道 copy_pages_data 建立的页表数据长什么样子。
总的来说，想要动态调试，我们首先需要编译一个带调试符号的 elf 文件出来，然后更新 hd.img 镜像文件。
接着我们用 QEMU 启动内核，具体命令如下：
最后，我们用 GDB 加载调试符号并调试，具体命令如下：
我已经将编译好的带调试符号的 elf 文件，以及对应的 hd.img 镜像文件放在了GitHub上，你可以直接用这些文件和上面的命令来调试。仓库中目前我只放了对应第十三课和第二十六课的调试文件，如果你想要调试其他课的代码，不妨继续往下看。
制作“带调试符号的 elf 文件"的详细步骤
如果你调试过 Linux 内核，应该比较熟悉上面的流程。不过在制作“带调试符号的 elf 文件”时，Cosmos 和 Linux 内核有些不同，下面我就详细说明一下。
先说说整体思路：通过修改编译选项，即可生成“带调试符号的 elf 文件”。然后再生成 Cosmos.eki 内核文件，最后替换 hd.img 镜像文件中的 Cosmos.eki 文件。这样，我们就可以用“带调试符号的 elf 文件”和 hd.img 来调试代码了。
修复两个 bug
只有先修复后面这两个 bug，才能成功编译，并且运行 Cosmos 内核代码。
第一个问题是：编译第十三课的代码时遇到一个报错，报错截图如下。
解决办法很简单：将 kernel.asm 文件中的“kernel.inc”修改成“/kernel.inc”，你可以对照后面的截图看一下。
第二个问题是第二十六课遇到的运行时报错，如下图所示。
因为 acpi 是和“电源管理”相关的模块，这里并没有用到，所以我们可以注释掉 initldr/ldrkrl/chkcpmm.c 文件中的 init_acpi 函数调用。
解决掉这两个问题，就可以成功编译第十三课和第二十六课的代码了。
修改“编译选项"
修复 bug 后，我们虽然能够成功编译运行，但是因为文件没有调试符号，所以我们在 GDB 调试时无法对应到 c 源码，也无法用函数名下断点。因此，我们需要通过修改编译选项来生成带调试符号的 elf 文件。
为了编译出带调试符号的执行文件，需要对编译脚本做两处修改。
第一处修改，GCC 的-O2参数要修改成O0 -g参数：-O0是告诉 GCC 编译器，在编译时不要对代码做优化，这么做的原因是避免在 GDB 调试时源码和实际程序对应不上的情况；-g参数是为了告诉编译器带上调试符号。
第二处修改，去掉 ld 的-s参数：-s是告诉 ld 程序链接时去掉所有符号信息，其中包括了调试符号。
需要替换和修改的文件位置如下图：
使用 sed 命令，即可批量将-O2 参数修改成-O0-g ，代码如下：
使用 sed 命令批量去掉 ld 的-s参数，代码如下：
完成上面的操作以后，编译选项就修改好了。
编译生成“带调试符号的 elf 文件"
我们修复 bug 和修改编译选项后，执行make就可以编译出带有调试符号的 elf 文件，如下图：这里的“not stripped”就表示文件带有调试符号。
这里有两个要点，我特别说明一下。
1.Cosmos.elf：当需要调试“内核代码”时，可以在 GDB 中执行symbol-file ./initldr/build/Cosmos.elf加载调试符号。
2.initldrkrl.elf：当需要调试“二级加载器代码”时，可以在 GDB 中执行symbol-file ./initldr/build/initldrkrl.elf加载调试符号。
重新制作 hd.img
最后一步，我们需要重新制作 hd.img，这样 VBox 或者 QEMU 就能运行我们重新生成的 Cosmos 内核。
整个过程很简单，分两步。首先生成 Cosmos.eki，这里需要注意的是，font.fnt 等资源文件要拷贝过来。
然后更新 hd.img，替换其中的 Cosmos.eki。
完成上面的操作以后，hd.img 就制作好了。现在我们可以用 hd.img 和之前生成的 elf 文件来调试代码。
打包传输 hd.img 到 mac
因为我是在云上购买的 Linux 虚拟机上调试 Mac 上 QEMU 运行的 Cosmos 内核，所以我需要把 Linux 上制作的 hd.img 传输到 Mac。你可以根据自己的实际情况设置传输地址。
如何通过动态调试验证 grub 镜像文件的加载过程
动态调试也好，汇编代码也罢，其实都是为我们分析问题和解决问题服务的。对于调试不太熟悉的小伙伴也别有太大心理负担，一回生、二回熟嘛，咱们多试试就有手感了。
接下来，我就给你分享个比较简单的案例，你只需要看到几行汇编代码，就能解决一些学习中的小疑问。
在正式讲解这个调试案例之前，我先交代下问题背景。在学习课程中的“初始化”部分时，我有两个疑问：
1. 代码从 grub 到 Cosmos 项目时，第一条指令是什么？这条指令被加载到哪里执行？
2. 此时 CPU 是实模式还是保护模式？
为了解决这两个疑问，我开始了自己的探索之旅。
分析过程
根据 11 | 设置工作模式与环境（中）：建造二级引导器课程中说的 GRUB 头结构，结合上面的 Cosmos.eki 文件头信息，我们很容易就能知道，_start符号地址是0x04000000,_entry符号地址是0x04000068。
所以，可以猜测：grub 程序会加载 cosmos.eki 到0x04000000位置，然后跳到0x04000000执行，再从0x04000000 jmp 到0x04000068。
我们可以使用 GDB 调试验证是否符合这个猜测，调试代码如下:
通过 GDB 可以看到，程序不是在0x04000000断点暂停，而是直接在0x04000068 断点暂停，说明第一条指令不是 _start 符号位置而是 _entry 符号位置。到 _entry 时，cr0 的 pe=1，这表明此时保护模式已经打开了。怎么样？是不是挺方便的？
经过前面的调试，我得到了最后的结论：第一条指令是 _entry 符号位置，地址是0x04000068。到0x04000068这一条指令时，CPU 已经是保护模式了。
我的分享到这里就告一段落啦。为了照顾刚入门的同学，我再提供两个参考资料。关于 GDB 的使用，你可以参考 100 个 GDB 小技巧。关于 QEMU、GCC、ld 等命令参数的含义，你可以参考 man 手册。
希望这篇加餐对你有所启发，如果你有什么好的学习方法，不妨也在留言区多多分享，让我们一起学习进步。
分享给需要的人，Ta购买本课程，你将得20元
生成海报并分享赞 14
提建议
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
用户故事 | 技术人如何做选择，路才越走越宽？
下一篇
用户故事 | yiyang：我的上机实验“爬坑指南”
精选留言(6)
Geek_504185置顶2021-12-30需要添加-g 的地方如下： 1:initldr/build/krnlbuildcmd.mh文件中 BTCFLGS ,CFLAGS,CPPFLGSLDS三处需要添加-O0 -g 2:外层build文件夹里的pretreatment.mkf的CPPFLGSLDS后面也添加-O0 -g 编译要就可以安装文章中操作边调试边显示代码了展开作者回复: 是的，感谢分享
1![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="72" height="72"><rect fill-opacity="0"/></svg>)
月鸟2021-12-17我是板凳! 千呼万唤始出来，等这篇调试等了3个星期了! 感谢你!作者回复: 哈哈 赶紧试试
共 2 条评论5
苏流郁宓2021-12-17很受用编辑回复: 加油
共 2 条评论3- 月鸟2021-12-18如果大家按照作者的详细步骤操作时出现如下之类的问题： warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. /etc/gdb/gdbinit:3: Error in sourced command file: Remote 'g' packet reply is too long (expected 308 bytes, got 608 bytes): 0000000000000000685301020080ffff0000000000000000ac2d00020080fffffe000000000000000000000000000000b0ff08000080ffff88ff08000080ffffff0000000000000000000000000000000000000000000000b025010000000000000000000000000000000000000000000000000000000000685301020080ffffe52d00020080ffff4600200008000000100000001000 这个问题是GDB调试64位Kernel时才有的，解决的方法是在进行gdb操作前先在(gdb)后面执行如下语句： (gdb) set architecture i386:x86-64:intel (gdb) target remote:1234 Remote debugging using :1234 (gdb) symbol-file Cosmos/build/Cosmos.elf Reading symbols from Cosmos/build/Cosmos.elf... (gdb) b *0x04000000 Breakpoint 1 at 0x4000000 (gdb) b *0x04000068 Breakpoint 3 at 0x4000068 (gdb) c Continuing. 玩吧！展开
作者回复: 6666
2 
摘星2022-06-08做完上面流程后 最后使用 qemu-system-x86_64 -drive format=raw,file=hd.img -m 512M -cpu kvm64,smep,smap -s 这个命令，qemu启动了，到grub菜单几秒后 依然弹出 错误提示："My computer is not support ACPI" 啊？ 我已经确定那个init_acpid函数已经注释了，也按照步骤 将hd.img更新了。作者回复: 可能是没做对
磊2022-03-27info all registers 怎么看不到cr0寄存器，搜索了一圈，也没找到gdb能显示cr0这一类控制寄存器的，请教下上图gdb这个怎么出来的？共 1 条评论
