From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16994 invoked by alias); 2 Oct 2007 22:54:15 -0000 Received: (qmail 16986 invoked by uid 22791); 2 Oct 2007 22:54:14 -0000 X-Spam-Check-By: sourceware.org Received: from va-65-40-217-47.sta.embarqhsd.net (HELO CVAEX1.VERTICAL.COM) (65.40.217.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 02 Oct 2007 22:54:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: No line number info debugging kernel modules with gdb 6.6.90.20070926-cvs (gdb 6.7 branch) Date: Tue, 02 Oct 2007 22:54:00 -0000 Message-ID: <4DD3AF7ECBBC43409BA36508938D01851B00FD@CVAEX1.VERTICAL.COM> In-Reply-To: From: "Jon Ringle" To: "Jim Blandy" , "Jon Ringle" Cc: Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00030.txt.bz2 Jim Blandy wrote: > Well, I'm pretty confused. >=20 > For starters, the output from 'maint print symbols' includes a line > 325, but the output from 'readelf -wil' shows no such line. >=20 > 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 output that I got from 'maint print symbols' and the output from 'readelf -wil' were from two different runs and I think I may have inserted some code between these two runs that may explain this inconsistency. I can do get you fresh output of all of it if you'd like. >=20 > The more inconsistencies you find, the more information you have about > the bug, I guess, but I can't see the unifying story here. >=20 > 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. Will do this tonight. >=20 > If that's what's going on, then it might help to connect to the target > before doing the add-symbol-file. Ok