Linux Help
guides forums blogs
Home Desktops Distributions ISO Images Logos Newbies Reviews Software Support & Resources Linuxhelp Wiki

Welcome Guest ( Log In | Register )



Advanced DNS Management
New ZoneEdit. New Managment.

FREE DNS Is Back

Sign Up Now
> Debugging loadable kernel modules using KGDB, I am having problems debugging a module with KGDB over serial.
droneprime
post Apr 28 2009, 12:52 PM
Post #1


Whats this Lie-nix Thing?
*

Group: Members
Posts: 2
Joined: 28-April 09
Member No.: 14,430



I am trying to use KGDB over serial in a 2.6.27.7-9 kernel for debugging a module. KGDB comes built-in with this kernel.
I want to debug a module. I have built the module with ‘-g3’ and ‘-O0’ options in the Makefile.
The kernel on the target machine was built on the development machine, with the source for the module in [kernel-source]/drivers/scsi/[module]/
I moved the vmlinuz, initrd, System.map and /lib/modules/[kernel-name] over to the target machine.
The target kernel boots, waits for GDB on the host side, and responds to ‘continue’ on the host side.
I am able to SysRq+g on the target to interrupt after the module of interest has been loaded. That returns control to GDB on the host.
At that point I am able to ‘add-symbol-file [path] [.text address]’ and the symbols load successfully.
I can then set a desired breakpoint using the symbols that I am interested in.
Then I hit continue on the development machine, and that lets the target continue booting.
Once the target completes booting, I run a test program that will trip that breakpoint by using that module.
It is at this point that the target locks up, as though the breakpoint has been tripped. However, the development machine does not return the GDB prompt to me. It just stays locked up with no prompt.

Do you have any idea what the problem is?

Thanks in advance.

P.S.
I Think I am using GDBMOD 2.4 from Amit Kale's site. I built the GDBMOD source and did a make install and that placed a 'gdb' in '/usr/local/bin'. I don't think that was there before, seeing as I made sure to install gdb at the time SUSE was installed.

'set solib-search-path [driver ko path]' does nothing (info sharedlibraries).
Go to the top of the page
 
+Quote Post
 
Start new topic
Replies (1 - 3)
chuckf
post Jun 10 2009, 03:26 PM
Post #2


Whats this Lie-nix Thing?
*

Group: Members
Posts: 2
Joined: 10-June 09
Member No.: 14,496



QUOTE (droneprime @ Apr 28 2009, 11:52 AM) *
I am able to SysRq+g on the target to interrupt after the module of interest has been loaded. That returns control to GDB on the host.

Is there anything you had to do to get the SysRq+g to work?

QUOTE (droneprime @ Apr 28 2009, 11:52 AM) *
Once the target completes booting, I run a test program that will trip that breakpoint by using that module.
It is at this point that the target locks up, as though the breakpoint has been tripped. However, the development machine does not return the GDB prompt to me.
It just stays locked up with no prompt.

I'm having a similar issue: once a breakpoint is encountered, the target locks up. Have you made any progress on this?

Thanks,
chuckf
Go to the top of the page
 
+Quote Post
droneprime
post Jun 30 2009, 01:39 PM
Post #3


Whats this Lie-nix Thing?
*

Group: Members
Posts: 2
Joined: 28-April 09
Member No.: 14,430



QUOTE (chuckf @ Jun 10 2009, 03:26 PM) *
Is there anything you had to do to get the SysRq+g to work?


Not really. Remember that it is Alt+SysRq+g, not just SysRq+g. I don't know, just a consideration.
I believe that if you poke around 'Kernel Hacking' in Menuconfig and look for MagicKey you can turn it on from there.

QUOTE (chuckf @ Jun 10 2009, 03:26 PM) *
I'm having a similar issue: once a breakpoint is encountered, the target locks up. Have you made any progress on this?


So, on my setup, KGDB would trip the breakpoint, hence, lockup. Yet, the Host didn't respond.
I found that SuSE was mucking up the tty speed before I caused the breakpoint to be tripped.
So, prior to tripping the breakpoint on the host, i run the following on both, just to be sure:

CODE
stty -F /dev/ttyS0 38400


That seems to fix everything. I can pass debug control back and forth now.
Hope this helps.
Go to the top of the page
 
+Quote Post
chuckf
post Jun 30 2009, 02:03 PM
Post #4


Whats this Lie-nix Thing?
*

Group: Members
Posts: 2
Joined: 10-June 09
Member No.: 14,496



QUOTE (droneprime @ Jun 30 2009, 12:39 PM) *
Not really. Remember that it is Alt+SysRq+g, not just SysRq+g. I don't know, just a consideration.
I believe that if you poke around 'Kernel Hacking' in Menuconfig and look for MagicKey you can turn it on from there.



So, on my setup, KGDB would trip the breakpoint, hence, lockup. Yet, the Host didn't respond.
I found that SuSE was mucking up the tty speed before I caused the breakpoint to be tripped.
So, prior to tripping the breakpoint on the host, i run the following on both, just to be sure:

CODE
stty -F /dev/ttyS0 38400


That seems to fix everything. I can pass debug control back and forth now.
Hope this helps.


I recently realized the same thing was happening on Fedora. I set the kgdb baud rate to 9600 to get it working.
I'll try the stty command sometime.

Thanks!
chuckf
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 20th October 2017 - 09:19 AM