是否可以使用gdb和qemu同时调试linux用户空间程序和内核空间？

Question

到目前为止,使用gdb + qemu,我可以进入/超过linux内核源代码.是否可以同时调试用户空间程序？例如,从用户空间到内核空间单步执行一个程序,这样我可以通过发出来观察qemu监视器上寄存器的变化info registers？

Answer 1

最少的逐步设置

Mahouk 是对的，但这里是一个完全自动化的 QEMU + Buildroot 示例，它假设您已经知道如何使用 QEMU + gdb 调试内核以及更详细的解释：

readelf -h myexecutable | grep Entry

给出：

  Entry point address:               0x4003a0

所以在GDB内部我们需要做：

add-symbol-file myexecutable 0x4003a0
b main

然后才在 QEMU 中启动可执行文件：

myexecutable

更可靠的方法是，如果可以的话，将其设置myexecutable为流程。init

add-symbol-file也提到：如何在 gdb 中加载多个符号文件

为什么你会想要这样做而不是gdbserver？

到目前为止我只能看到一个用例：debugging init: Debug init on Qemu using gdb

否则，为什么不直接使用以下更可靠的方法，例如进入系统调用：

• 启动两个远程 GDB：
  • 一个与qemu-system-* -s
  • 另一个gdbserver myexecutable解释如下：https://reverseengineering.stackexchange.com/questions/8829/cross-debugging-for-mips-elf-with-qemu-toolchain/16214#16214
• step ingdbserver的 GDB 尽可能接近系统调用，这通常意味着单步进入 libc
• 在 QEMU 的 GDB 上，执行b sys_readread 系统调用
• 回来gdbserver，做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

Answer 2

我通过使用 gdb 命令 add-symbol-file 添加用户空间程序调试信息来实现它。但你必须知道这些程序的加载地址。所以准确地说，你必须像平常一样通过连接 gdb 到 gdbserver 来启动内核调试；然后，您可以添加这些程序调试信息。不过，您也可以使用 .gdbinit 脚本。读这个