Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

module debugging through KGDB

I want to debug my kernel module. For that I am trying to put a breakpoint at do_one_initcall in kernel/module.c just before my init_module gets called but it's displaying

Cannot access memory at address 0x802010a0

Below is the Makefile which I am using:

obj-m := hello.o

KDIR=/lib/modules/$(shell uname -r)/build
PWD=$(shell pwd)

EXTRA_CFLAGS += -g

all:
        make -C $(KDIR) M=$(PWD) modules

clean:
        make -C $(KDIR) M=$(PWD) clean

Please suggest me what could be the problem.

like image 278
cp5662 Avatar asked Jun 07 '11 05:06

cp5662


1 Answers

A loadable kernel module's location in the memory is set only upon insertion of the module. When you set a breakpoint on a module function, gdb consults the module file (.ko) for the address, which is wrong. You need to inform gdb of the actual location of the module.

You can consult this book (chapter 4, Debuggers and related tools section) for more information, but here's a short procedure that I devised for doing that.

  • machine1 is the debugged machine.
  • machine2 is the machine running the debugger.

  1. On machine1, run modpbrobe your_module_name
  2. On machine1, run the following shell commands:
    MODULE_NAME=your_module_name
    MODULE_FILE=$(modinfo $MODULE_NAME| awk '/filename/{print $2}')
    DIR="/sys/module/${MODULE_NAME}/sections/"
    echo add-symbol-file $MODULE_FILE $(cat "$DIR/.text") -s .bss $(cat "$DIR/.bss") -s .data $(cat "$DIR/.data")
    you should get an output similar to the following:
    add-symbol-file /lib/modules/.../your_module_name.ko 0xffffffffa0110000 -s .bss 0xffffffffa011b948 -s .data 0xffffffffa011b6a0
  3. On machine2, run gdb vmlinux.
  4. On machine2, on the gdb console, run the output of the final command in stage 2.
  5. On machine2, on the gdb console, connect to machine1 by running target remote /dev/ttyS0 (assuming your serial port is at ttyS0)
  6. On machine1, run echo g > /proc/sysrq-trigger. The machine will freeze
  7. On machine2, on the gdb console, set the breakpoint as you wish.
  8. Continue debugging. The breakpoint should be triggered when it needs to.
There could be other issues that prevent you from setting the breakpoint, but this is the main hurdle to cross.
like image 101
Nir Avatar answered Sep 22 '22 23:09

Nir