Can gdb and qemu be used to simultaneously debug Linux user space programs and kernel space?

Question

So far with gdb + qemu I can go in / on top of the Linux kernel source code. Is it possible to debug user space programs at the same time? For example, one step is a program from user space to kernel space, so I can observe the register changes on the qemu monitor by issuing info registers ?

Answer 1

I achieve it by using the add-symbol command of the gdb file to add user-space program debugging information. But you must know these downloadable program addresses. therefore, to be precise, you need to start kernel debugging by connecting gdb to gdbserver, as usual; and then you can add this information to debug programs. You can also use the .gdbinit script. Read this

Answer 2

Minimum step-by-step setup

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

 readelf -h myexecutable | grep Entry 

gives:

  Entry point address: 0x4003a0 

So, inside GDB we need to do:

 add-symbol-file myexecutable 0x4003a0 b main 

And only then run the executable in QEMU:

 myexecutable 

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

Why would you do this instead of gdbserver ?

So far I see only one use case: debugging init : Debugging init on Qemu using gdb

Otherwise, why not just use the following more reliable method, for example. to go to syscall:

• run two remote gdb:
  • one with qemu-system-* -s
  • another gdbserver myexecutable , as described in: https://reverseengineering.stackexchange.com/questions/8829/cross-debugging-for-mips-elf-with-qemu-toolchain/16214#16214
• a step in gdbserver gdb as close as possible to the system call, which often means going to libc
• on GDB QEMU e.g. b sys_read to read syscall
• back to gdbserver , do continue

I suggest this because:

• using QEMU GDB for the user area can lead to random transitions as the kernel context switches to another process that uses the same virtual addresses.

• I was not able to load shared libraries correctly 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'. 

  As a result, since most kernel interactions go through stdib, you will need to take many smart build steps to find a kernel entry, which can be impractical.

  Until someone writes smarter GDB scripts that will execute each command until a context switch occurs or until the source is available. I wonder if such scripts will not be too slow, since the naive approach has the overhead of communication from GDB for each instruction.

  This may get you started: Report gdb missing standard files