Printable Version of Topic

Click here to view this topic in its original format

Linuxhelp _ Technical Support _ Debugging loadable kernel modules using KGDB

Posted by: droneprime Apr 28 2009, 12:52 PM

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).

Posted by: chuckf Jun 10 2009, 03:26 PM

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

Posted by: droneprime Jun 30 2009, 01:39 PM

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.

Posted by: chuckf Jun 30 2009, 02:03 PM

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)