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

Question

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

Answer 1

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

Answer 2

最小的逐步设置

Mahouk is right，但这里有一个fully automated QEMU + Buildroot example，它预示着你already know how to debug the kernel with QEMU + gdb和一个更详细的说明：

readelf -h myexecutable | grep Entry

给出：

  Entry point address:               0x4003a0

所以我们需要做GDB内部：

add-symbol-file myexecutable 0x4003a0
b main

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

myexecutable

更可行的方法是将myexecutable设置为init进程，如果可以的话。

您为什么要这样做而不是gdbserver？

到目前为止，我只能看到一个用例：调试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
  所述
• 步入gdbserver的GDB尽可能接近系统调用，这通常意味着进入libc
• 在QEMU的GDB上，例如对于read syscall
，b sys_read
• 返回gdbserver，执行continue

我建议这样做是因为：

• 使用QEMU GDB for userland可以导致随机跳转，因为内核上下文切换到使用相同虚拟地址的另一个进程

• 我没有gdbserver无法正确加载共享库：尝试sharedlibrary直接给出：

  (gdb) sharedlibrary ../../staging/lib/libc.so.0
  No loaded shared libraries match the pattern `../../staging/lib/libc.so.0'.
  

  因此，由于大多数内核交互都通过stdib，因此您需要执行大量智能程序集步骤来查找内核条目，这可能是不切实际的。

  直到有人编写一个更智能的GDB脚本来执行每个指令，直到上下文切换发生或源变为可用。我想知道这些脚本是不是太慢了，因为天真的方法有来自GDB的每条指令的通信开销。

  这可能会让您入门：Tell gdb to skip standard files