STLinux

GDB is able to detect when a module is loaded on the target. It will then load the module object file into the memory of GDB to get debugging information.

The search path where GDB locates module files is set in the variable solib-search-path.

1. On the target, load your module:

target# insmod my_mod.ko

2. Stop the kernel execution to confirm that the module is indeed loaded.

3. On the host load the module symbols and set your breakpoints:

host% sh4-linux-gdb vmlinux
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, 
and you are welcome to change it and/or distribute copies of it 
under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  
Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=sh4-linux"...
0x84031f10 in ?? ()
 
Automatically enabled KGDB extensions...
(gdb) set solib-search-path /user/my_module_2.6/
Reading symbols from /user/my_module_2.6/my_mod.ko...
expanding to full symbols...done.
Loaded symbols for /user/my_module_2.6/my_mod.ko
(gdb) info sharedlibrary
From        To          Syms Read   Shared Object Library
0xc0168000  0xc01680c0  Yes         /user/my_module_2.6/my_mod.ko
(gdb) b mod_stm_open
Breakpoint 1 at 0xc0168002: file /user/my_module_2.6/my_mod.c, line 43.
(gdb) c
Continuing.

In order to understand where the loadable module symbols are located, GDB needs to be connected to the target (where your modules have been loaded). This means that the command set solib-search-path /user/my_module_2.6/ must be run after GDB has connected to the target; otherwise it collects the symbols but it doesn't know where they are located.

This issue can be resolved using the pending breakpoints.

Problems may also occur when unloading modules if GDB still has breakpoints within the module. For example, if you unload a module (using the rmmod command), without removing all the relevant breakpoints in GDB, any attempt to start a new debug session (for example stopping the kernel execution with Ctrl+C) will cause the system to hang. This is because KGDB is being asked to perform actions on the active breakpoints which are no longer accessible.

Debugging module_init and module_exit functions

A simple procedure is needed to debug the module_init function from a module.

Before loading you module, you can set a pending breakpoint on the module_init function, as shown below. So you will be able to debug it as soon as your module will be loaded.

(gdb)file vmlinux
(gdb)set breakpoint pending on
(gdb)set solib-search-path /user/my_module_2.6/
(gdb)info sharedlibrary
(gdb)b my_module_init

Currently, this method only works if you write in your C code the module_init function without the __init attribute. In the same way you have to write the module_exit function without the __exit attribute.

Configuring GDB to debug a module

Debugging can be simplified by defining a personal set of GDB commands. This is done using the GDB define command in a file which GDB will read when it is started.

set auto-solib-add 0
 
define mymod
  set solib-search-path /user/my_module_2.6/
  info sharedlibrary
end
 
define kgdbserial
set remotebaud 115200
target remote /dev/ttyS0
end
 
define kgdb_start
set linux-awareness auto_activate 0
file vmlinux
set auto-solib-add 1
kgdbserial
end

Note: in any case, the developer can use a personal configuration file as shown below:

host% sh4-linux-gdb --command .my_gdbinit