pwndbg: pwndbg cannot show source when debugging Linux kernel

Description

When debugging the kernel through QEMU’s remote gdbserver, pwndbg cannot show the source, but only the disassembly. However, vanilla gdb has no problem displaying the source while debugging. In fact, if I start a remote debugging session, and then hit <Ctrl+2>, I can see the source.

Steps to reproduce

  1. Start QEMU as a gdbserver:
qemu-system-x86_64 -S -s -kernel arch/x86_64/boot/bzImage -drive \
format=raw,file=wheezy.img -m 2046 -nographic -append "root=/dev/sda \
console=ttyS0 rw single nokaslr"
  1. Start gdb with the vmlinux symbol file, connect to the remote server, set a breakpoint, and start the boot process (NB: this assumes that the kernel was built with debug symbols):
gdb vmlinux
pwndbg> target remote :1234
pwndbg> b fat_fill_super
pwndbg> continue

When the breakpoint is hit, only the disassembly is shown. There is an error report: ERROR: Could not find ELF base!

My setup

pwndbg> version
Gdb:      GNU gdb (Ubuntu 8.0.1-0ubuntu1) 8.0.1
Python:   3.6.3 (default, Oct  3 2017, 21:45:48)  [GCC 7.2.0]
Pwndbg:   1.0.0 build: e225ba9
Capstone: 4.0.1024
Unicorn:  1.0.1

QEMU 2.10.1

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 16 (13 by maintainers)

Most upvoted comments

I also have had this issue for a while.

Generally, as @disconnect3d says, there’s very poor support for kernel debugging, and the problems are spread out across the code base as there’s numerous assumptions that only work for user-land. For example, a lot of stuff in pwndbg/elf.py does plainly not work for vmlinux debugging.

In my opinion, it will be a major undertaking adding “first-class” support for kernel debugging (whether it be QEMU or hardware), for all the reasons @disconnect3d have mentioned here, and in related issues like #736.

I have some local patches here: https://github.com/jonaskaempf/pwndbg/tree/vmlinux-dev, that hacks a few places to get rid of the most annoying errors and exceptions to actually get a somewhat durable UX, at least for the simplest case: QEMU+vmlinux with symbols. It’s not intended as a merge request, more a hack on top of several other hacks. Especially the very hackish user-land-only functions in pwndbg/elf.py could use a major refactor.

Also there’s the issue of memory maps, stack finding etc. that break all over the place when debugging kernel. But it seems most of these errors are not fatal in the sense that you can get a usable experience without “fixing” them.

Finally, there’s lots of cool kernel debugging features that could be added when the basis mentioned above is in place; e.g. getting info on current userland process, if breaking inside userland mode etc.

The kernel debugging experience isn’t great, but it’s gotten a bit better over the past few years and will be a bigger focus next year. I’ve been debugging x86 and aarch64 linux kernels recently and haven’t had any problems with seeing the source, so I think we should close this.