| |||||||||||||
How we use GDB on LKMs todayHow we use GDB on LKMs todayPosted Jun 25, 2004 18:11 UTC (Fri) by giraffedata (subscriber, #1954)Parent article: Debugging kernel modules This is a welcome usability enhancement to GDB with the kernel, but the situation isn't as dire today as the article makes it sound. People debug loadable kernel modules with GDB all the time by using the -m option on 'insmod' to get that section location information. kgdb.sourceforge.net has a program that does the insmod and generates a convenient gdb script you can invoke to do the appropriate add-symbol-file. The drawback is that you have to plan in advance -- and have to do a special load of the module. With Jon's work, the information is always there. Well, not exactly. You still have to plan ahead and look at the sysfs file before gdb gets entered and the system stops. With current Kgdb (kgdb.sourceforge.net), There's a mechanism where Gdb automatically knows where the modules are loaded. But something about it makes Gdb annoyingly slow, so I abandonned it and can't say much about it.
(Log in to post comments)
How we use GDB on LKMs today Posted Jun 25, 2004 18:37 UTC (Fri) by corbet (editor, #1) [Link] "People debug loadable kernel modules with GDB all the time by using the -m option on 'insmod' to get that section location information." Yes, people do that when developing for 2.4 kernels, where insmod has a clue of where the sections live. In 2.6, the section layout is done inside the kernel itself, so insmod could not tell you where the sections ended up even if it did still support the -m option, which it doesn't...
|
|||||||||||||