This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: No line number info debugging kernel modules with gdb 6.6.90.20070926-cvs (gdb 6.7 branch)
- From: Jim Blandy <jimb at codesourcery dot com>
- To: Jon Ringle <jon at ringle dot org>
- Cc: Jon Ringle <JRingle at vertical dot com>, gdb at sourceware dot org
- Date: Tue, 02 Oct 2007 14:37:54 -0700
- Subject: Re: No line number info debugging kernel modules with gdb 6.6.90.20070926-cvs (gdb 6.7 branch)
- References: <4DD3AF7ECBBC43409BA36508938D01851B00AE@CVAEX1.VERTICAL.COM> <m3d4w3lkkb.fsf@codesourcery.com> <46FC7961.2080706@ringle.org> <m3odfmqysb.fsf@codesourcery.com> <46FD72CE.9080603@ringle.org> <m3ejgie4fc.fsf@codesourcery.com> <20070929002707.GA6310@caradoc.them.org> <46FDAA42.6060105@ringle.org> <20070929020649.GA10700@caradoc.them.org> <46FDB801.5010401@ringle.org>
Well, I'm pretty confused.
For starters, the output from 'maint print symbols' includes a line
325, but the output from 'readelf -wil' shows no such line.
Then, GDB has set the breakpoint on vert_dst_nopage_mmap at
0xbf1342b4, but 'maint print symbols' says that function's block
covers the addresses 0xbf13434c..0xbf1343b4, which doesn't cover the
breakpoint's address.
The more inconsistencies you find, the more information you have about
the bug, I guess, but I can't see the unifying story here.
One last thing: John, could you 'set debug remote 1' before connecting
to your target, and see if it's sending a 'qOffsets' packet? If it
does, then that gets applied to symfile_objfile, which in your case
would have been dstdrv.ko. But I'd expect any qOffsets received from
the kernel to be meant for vmlinux; the remote stub has no idea you've
loaded dstdrv.ko.
If that's what's going on, then it might help to connect to the target
before doing the add-symbol-file.