2

I am wondering if it is possible to debug a kernel module being loaded.

Note I am currently trying this on Linux 2.0.18. I've followed this great tutorial. Since the kernel config options CONFIG_PROC_KCORE and CONFIG_DEBUG_INFO don't seem to be available in this kernel version, I've added -g -gdwarf to CFLAGS in the Makefile, recompiled the kernel and modules and rebooted.

Then I can run gdb vmlinux /proc/kcore and then p jiffies which gives me $1 = 1470917.

That's where I am starting to get lost, also because there seems to be no /sys/module/gdb1/sections on that kernel version, as it seems required to debug a loaded module.

So I just tried to load the symbols of the module "ne":

(gdb) symbol-file modules/ne.o

which loads the symbols after confirming with "y". Then I set a breakpoint:

(gdb) break ne.c:148
Breakpoint 1 at 0xa: file ne.c, line 148.

Now I'd like to do modprobe ne and reach the breakpoint, but I think I am completely on the wrong path.

Is it possible at all? Even if it is not on such an old kernel, I'd be happy to know how to debug a module being loaded on a current kernel as well.

Torsten Römer
  • 3,834
  • 4
  • 40
  • 53

1 Answers1

2

The very document you are linking states you can't use breakpoints when debugging. Otherwise you could deadlock the kernel by accident (e.g. what if the thread blocking on a breakpoint has a spinlock the debugger needs to take to inspect the thread?), also there is no stable state as the kernel needs to keep running.

I can only speculate why this method was described. My guess is years ago there was not much choice when few people had hardware supporting virtualisation or multiple machines to debug remotely.

The way to go about is to use something like qemu and attach to the vm from the host. http://wiki.osdev.org/Kernel_Debugging

Also, for post mortem debugging you can use https://people.redhat.com/anderson/crash_whitepaper/