到目前为止，使用 gdb + qemu，我可以单步执行 Linux 内核源代码。是否可以同时调试用户空间程序？例如，将程序从用户空间单步执行到内核空间，这样我就可以通过发出以下命令来观察 qemu 监视器上寄存器的变化info registers?
最少的分步设置
马胡克是对的，但这里有一个全自动 QEMU + Buildroot 示例这假设你已经知道如何使用 QEMU + gdb 调试内核以及更详细的解释：
readelf -h myexecutable | grep Entry
Gives:
Entry point address: 0x4003a0
所以在GDB内部我们需要做：
add-symbol-file myexecutable 0x4003a0
b main
然后才在 QEMU 中启动可执行文件：
myexecutable
更可靠的方法是设置myexecutable as the init如果你能做到的话，请进行处理。
add-symbol-file还提到：如何在gdb中加载多个符号文件
为什么你会想要这样做而不是gdbserver?
到目前为止我只能看到一个用例：调试init: 使用 gdb 在 Qemu 上调试 init
否则，为什么不直接使用以下更可靠的方法，例如进入系统调用：
- start two remote GDBs:
- 一个与
qemu-system-* -s
- 另一个
gdbserver myexecutable解释如下：https://reverseengineering.stackexchange.com/questions/8829/cross-debugging-for-mips-elf-with-qemu-toolchain/16214#16214
- step in
gdbserver的GDB尽可能接近系统调用，这通常意味着单步进入libc
- 在 QEMU 的 GDB 上，执行例如
b sys_read对于读系统调用
- back on
gdbserver, do continue
我提出这个建议是因为：
-
当内核上下文切换到另一个使用相同虚拟地址的进程时，将 QEMU GDB 用于用户区可能会导致随机跳转
-
如果没有，我无法正确加载共享库gdbserver: 尝试sharedlibrary直接给出：
(gdb) sharedlibrary ../../staging/lib/libc.so.0
No loaded shared libraries match the pattern `../../staging/lib/libc.so.0'.
因此，由于大多数内核交互都通过 stdib，因此您需要执行大量智能汇编步骤来查找内核条目，这可能不切实际。
也就是说，直到有人编写了更智能的 GDB 脚本，该脚本会逐步执行每条指令，直到发生上下文切换或直到源可用为止。我想知道这样的脚本是否会太慢，因为简单的方法会产生每条指令与 GDB 之间通信的开销。
这可能会帮助您开始：告诉 gdb 跳过标准文件
解析Linux内核数据结构
为了正确地进行用户态进程调试，这就是我们最终要做的：Linux 内核的线程感知 gdb
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
