views:

179

answers:

3

Hi all,

I have compiled my own Kernel module and now I would like to be able to load it into the GNU Debugger GDB. I did this once, a year ago or so to have a look at the memory layout. It worked fine then, but of course I was too silly to write down the single steps I took to accomplish this... Can anyone enlighten me or point me to a good tutorial?

Thank you so much

+3  A: 

It has been a while since I was actively developing drivers for Linux, so maybe my answer is a bit out of date. I would say you cannot use GDB. If at all, only to debug post mortem on dump files. To debug you should rather use a kernel debugger. Build the kernel with a kernel debugger enabled (there is one out-of-the box debugger for 2.6, which was lacking at the time I was active). I used the kernel patches for KDB from Sun ftp://oss.sgi.com/www/projects/kdb/download/, which I was quite happy with. A user space tool won't be of much use unless new gdb communicate somehow with the internal kernel debugger (which anyway you would have to activate)

I hope this gives you at least some hints, while not being a detailled answer. Better than no answer at all. Regards.

jdehaan
+1  A: 

I suspect what you did was

gdb /boot/vmlinux /proc/kcore

Of course you can't actually do any debugging, but it's certainly good enough to have a poke around the kernel.

stsquad
+1  A: 

For kernels > 2.6.26 (i.e. after May 2008), the preferred way is probably to use "kgdb light" (not to be confused with its ancestor kgdb, available as a set of kernel patches). "kgdb light" is now part of the kernel (in by default in current Ubuntu kernels, for instance), and it's capabilities are improving fast (Jason Wessel is working on it - possible google key).

Drawback: You need two machines, the one you're debugging and the development machine (host) where gdb runs. Currently, those two machines can only be linked through a serial link. kgdb runs in the target machine where it handles the breakpoints, stepping, etc. and the remote debugging protocol use to talk with the development machine. gdb runs in the development machine where it handles the user interface. An USB-to-serial adapter works OK on the development machine, but currently, you need a real UART on the target machine - and that's not so frequent anymore on recent hardware.

The (terse) kgdb documentation is in the kernel sources, in Documentation/DocBook

I suggest you google around for "kgdb light" for the complete story. Again, don't confuse kgdb and kgdb light, they come together in google searches but are mostly different animals. In particular, info from linsyssoft.com relate to the "ancestor" kgdb, so try queries like:

kgdb module debugging -"linsyssoft.com" -site:linsyssoft.com

and discard articles prior to May 2008 / 2.6.26 kernel. Finally, for module debugging, you need to manually load the module symbols in the dev machine for all the code and sections you are interested in. That's a bit too long to address here, but some clues there, there and there. Bottom line is, kgdb is a very welcome improvement but don't expect this trip to be as easy as running gdb in user mode. Yet. :)

filofel