Latest LQ Deal: Latest LQ Deals
Go Back > Forums > Linux Forums > Linux - Software
User Name
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.


  Search this Thread
Old 07-08-2009, 06:45 PM   #1
LQ Newbie
Registered: Aug 2008
Location: /dev/null
Distribution: Gentoo at home. Everything at work.
Posts: 24

Rep: Reputation: 15
KGDB breakpoint problem.

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!
Old 07-08-2009, 07:19 PM   #2
Senior Member
Registered: Dec 2004
Location: Olympia, WA, USA
Distribution: Fedora, (K)Ubuntu
Posts: 4,187

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354
Can't help you, but $1500 sounds downright cheap for the service offered!
Old 07-09-2009, 10:49 AM   #3
LQ Newbie
Registered: Aug 2008
Location: /dev/null
Distribution: Gentoo at home. Everything at work.
Posts: 24

Original Poster
Rep: Reputation: 15
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.

Old 09-08-2009, 12:03 PM   #4
LQ Newbie
Registered: Aug 2009
Posts: 8

Rep: Reputation: 0
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:


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
problem using kgdb 1.5 with 2.4.20-8 Surekha Gupta Linux - Newbie 1 01-03-2006 04:06 AM
problem connecting remote target using kgdb 1.4 with linux 2.4.20-8 Surekha Gupta Linux - Newbie 1 01-03-2006 04:06 AM
problem connecting remote target using kgdb 1.4 with linux 2.4.20-8 Surekha Gupta Linux - Newbie 1 01-03-2006 04:02 AM
problem connecting remote target using kgdb 1.5 with linux 2.4.20-8 Surekha Gupta Linux - Newbie 1 01-03-2006 04:01 AM > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 01:52 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration