So I've been working (fighting) with KGDB some time now.

I have KGDB enabled in the distributed kernel that came with OpenSUSE 11.1. I have two of the EXACT same computer. One of them builds the kernel fine, and the other boots that built kernel fine.

Not only can I boot that kernel, but I can set and trip breakpoints in kernel code. No problem.

The problem begins when I try to set a breakpoint in a loadable kernel module. Our company has a driver for our product, and this driver builds and inserts no problem.

I begin the session on the target, booting it. It boots to the KGDB enabled kernel and appropriately waits for a connection from remote GDB. I then switch over to the host and start a GDB session. I will omit the parameters I use to connect to the target because that portion seems to work fine. Once GDB is connected I can hit 'c' to continue execution.

Note: GDB in this document refers to GDBMOD-2.4, a special version of GBD 6.0 that Amit Kale claims to support module debugging in KGDB.

After the target is fully booted I found that you must reset the tty speed because SUSE does something funny with that. I haven't looked into it that deeply because a simple 'stty' fixes the communication problem I had. Once the line speed is properly set, I can trip a manual breakpoint with 'echo g > /proc/sysrq-trigger'. This will halt the target kernel and return control to the GDB host.

At this point I would like to configure GDB to recognize when a module is loaded on the target side. The GDB command 'set solib-search-path [path-to-driver.ko]' SHOULD, "automatically recognize that a kernel module has been loaded on the target computer". (I was quoting from the documentation there. This command appears to do nothing. After entering a solib-search-path I return control to the target and insmod the ko file. I then send control back to the host and check to see if ‘info sharedlibraries’ provides me with any information. Nothing. No shared libraries loaded at this time.

So the documentation provided with KGDB is flat out wrong. Or I have missed something? I REALLY hope it is the latter, because I have been working on this for so long.
I even tried to go back to the old commands from previous documentation, ‘add-symbol-file [path-to-driver] –d [.text hex address]’. This syntax, amazingly enough, WORKS. Kind of.
When I execute the command, GDB will load and find all the symbols for my driver. I can then set specific breakpoints in my driver code. The breakpoints even trip as I would expect them to. However, this is all rendered useless because EVERY tripped breakpoint appears to be coming from “io.h: line 34”. Every breakpoint I try that resides within my driver code (according to KGDB) originates from io.h line 34. It seems like garbage.

What is io.h? Why do my breakpoints go there? Why did I write so much?
I can answer the last one: Because I am hopelessly stuck and really need some help. Amit Kale (supposed maintainer of this code) refuses to help without a $1500 support charge. I understand that he needs to be compensated, but why was this included in the mainline linux kernel if there is no support anywhere?

Sorry, ranting. I need to stop that. Please help guys!

Can't help you, but $1500 sounds downright cheap for the service offered!

I'll save this thread and keep that in mind.

Still, one would think that there are some out there who have dealt with this, and I would hope that they frequent this site.

Thanks.

Hello, Dronepine, I am having a very similar problem meaning I can't
step or list the source file using gdb after I insmod my target debug
(.ko) module. Did you ever get a solution on this?

See more details re:my problem at:

http://www.linuxquestions.org/questi...h-kgdb-752688/