views:

207

answers:

1

I am using remote (k)gdb to debug a problem in a module that causes a panic when loaded e.g. when init() is called.

The stack trace just shows that do_one_initcall(mod->init) causes the crash. In order to get the symbol file loaded in the gdb, I need to get the address of the module text section, and to get that I need to get the module loaded.

Because the insmod in busybox (1.16.1) doesn't support -m so I'm stuck to grep modulename /proc/modules + adding the offset from nm to figure out the address.

So I'm facing a sort a of a chicken and an egg problem here - to be able to debug the module loading, I need to get the module loaded - but in order to get the module loaded, I need to debug the problem...

So I am currently thinking about two options - is there a way to get the address information either:

  1. by printk() in the module init code
  2. by printk() somewhere in the kernel code

all this prior to calling the mod->init() - so I could place a breakpoint there, load the symbol file, hit c and see it crash and burn...

+2  A: 

Can you build your code into the kernel rather than as a module? That might simplify debugging the init() call.

You could also set a breakpoint at do_one_initcall() and look at the address of mod->init to get the load address.

JayM
Compiling the code into kernel would be way too cumbersome (the need to flash the board every time as opposed to wget to a ramdisk). breaking in `do_one_initcall()` helped enough to pinpoint the problem so that I could postpone the crash until starting an usermode process communicating with the module. Thanks.
Kimvais