是否可以使用 gdb 和 qemu 同时调试 linux 用户空间程序和内核空间? [英] Is it possible to use gdb and qemu to debug linux user space programs and kernel space simultaneously?

问题描述

到目前为止，使用 gdb + qemu，我可以进入/跳过 linux 内核源代码.是否可以同时调试用户空间程序?例如，将程序从用户空间单步执行到内核空间，这样我就可以通过发出 info registers?

So far, with gdb + qemu, I can step into/over linux kernel source code. Is it possible to debug the user space programs simultaneously? For example, single step a program from user space to kernel space so I can observe the changes of registers on the qemu monitor by issuing info registers?

推荐答案

最小化 step-by-setep 设置

Mahouk 是对的，但这里有一个 全自动 QEMU + Buildroot 示例 前提是您已经知道如何用 QEMU + gdb 调试内核 和更详细的解释:

Mahouk is right, but here is a fully automated QEMU + Buildroot example which presuposes that you already know how to debug the kernel with QEMU + gdb and a more detailed exaplanation:

readelf -h myexecutable | grep Entry

给出:

  Entry point address:               0x4003a0

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

So inside GDB we need to do:

add-symbol-file myexecutable 0x4003a0
b main

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

And only then start the executable in QEMU:

myexecutable

一种更可靠的方法是将 myexecutable 设置为 init 进程(如果可以的话).

A more reliable way to do that is to set myexecutable as the init process if you can do that.

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

为什么要这样做而不是 gdbserver?

到目前为止，我只能看到一个用例:调试 init:使用 gdb 在 Qemu 上调试初始化

I can only see one use case for this so far: debugging init: Debug init on Qemu using gdb

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

Otherwise, why not just use the following more reliable method, e.g. to step into a syscall:

• 启动两个远程 GDB:
  • 一个带有 qemu-system-* -s
  • 另一个 gdbserver myexecutable 解释如下:https://reverseengineering.stackexchange.com/questions/8829/cross-debugging-for-mips-elf-with-qemu-toolchain/16214#16214
  • start two remote GDBs:
    • one with qemu-system-* -s
    • the other gdbserver myexecutable as explained at: https://reverseengineering.stackexchange.com/questions/8829/cross-debugging-for-mips-elf-with-qemu-toolchain/16214#16214

    我提出这个是因为:

    • 将 QEMU GDB 用于用户空间会导致随机跳转，因为内核上下文切换到另一个使用相同虚拟地址的进程

    • using the QEMU GDB for userland can lead to random jumps as the kernel context switches to another process that uses the same virtual addresses

    如果没有 gdbserver，我无法正确加载共享库:尝试 sharedlibrary 直接给出:

    I was not able to load shared libraries properly without gdbserver: attempting sharedlibrary directly gives:

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

    因此，由于大多数内核交互都通过 stdib，您需要执行大量智能汇编单步执行才能找到内核条目，这可能是不切实际的.

    As a consequence, since most kernel interactions go through the stdib, you would need to do a lot of smart assembly stepping to find the kernel entry, which could be impractical.

    直到，也就是说，有人编写了一个更智能的 GDB 脚本，它会逐步执行每条指令，直到上下文切换发生或源可用为止.我想知道这样的脚本会不会太慢，因为幼稚的方法会为每条指令带来与 GDB 之间的通信开销.

    Until, that is, someone writes a smarter GDB scripts that steps every instruction until a context switch happens or until source become available. I wonder if such scripts would't be too slow, as the naive approach has the overhead of communication to-from GDB for every instruction.

    这可能会让您开始:告诉 gdb 跳过标准文件

    解析Linux内核数据结构

    为了正确进行用户态进程调试，这就是我们最终必须做的:Linux 内核的线程感知 gdb

    To do userland process debug properly, that's what we would have to do eventually: thread-aware gdb for the Linux kernel

    这篇关于是否可以使用 gdb 和 qemu 同时调试 linux 用户空间程序和内核空间?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！