From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19232 invoked by alias); 2 Oct 2007 21:38:02 -0000 Received: (qmail 19224 invoked by uid 22791); 2 Oct 2007 21:38:01 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 02 Oct 2007 21:37:57 +0000 Received: (qmail 24714 invoked from network); 2 Oct 2007 21:37:55 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 Oct 2007 21:37:55 -0000 To: Jon Ringle Cc: Jon Ringle , gdb@sourceware.org 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> <46FC7961.2080706@ringle.org> <46FD72CE.9080603@ringle.org> <20070929002707.GA6310@caradoc.them.org> <46FDAA42.6060105@ringle.org> <20070929020649.GA10700@caradoc.them.org> <46FDB801.5010401@ringle.org> From: Jim Blandy Date: Tue, 02 Oct 2007 21:38:00 -0000 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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/msg00024.txt.bz2 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.