From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6510 invoked by alias); 20 Oct 2003 14:31:00 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6503 invoked from network); 20 Oct 2003 14:30:58 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 20 Oct 2003 14:30:58 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1ABb3h-0007be-LN; Mon, 20 Oct 2003 10:30:57 -0400 Date: Mon, 20 Oct 2003 14:31:00 -0000 From: Daniel Jacobowitz To: Michal Ludvig Cc: GDB Patches Subject: Re: [RFA] Find the most specific symtab Message-ID: <20031020143057.GA29121@nevyn.them.org> Mail-Followup-To: Michal Ludvig , GDB Patches References: <3F93F058.5060104@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F93F058.5060104@suse.cz> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00615.txt.bz2 On Mon, Oct 20, 2003 at 04:25:28PM +0200, Michal Ludvig wrote: > Hi, > when debugging modules in linux kernel one must load symtab from each > module using add-symbol-file command. However find_pc_sect_psymtab() > returns with the first, usually less specific entry among all psymtabs > instead of the newly added one, which leads to a situation where the > wrong source file is chosen and therefore the "next", "next", ... > stepping is unusable. > > The attached patch modifies find_pc_sect_psymtab() so that it always > returns the most specific symtab. Typical debugging session with > verbosity tured on now looks like: > $ ./gdb /share/linux-2.4.21-2-mludvig/vmlinux > GNU gdb 2003-10-20-cvs > [...] > (gdb) add-symbol-file /share/lkm/lkm.o 0xffa00180c0 > add symbol table from file "/share/lkm/lkm.o" at > .text_addr = 0xffa00180c0 > (y or n) y > Reading symbols from /share/lkm/lkm.o...done. > (gdb) set verbose > (gdb) l lkm_exit > More symtabs for PC=0xffffffffa00181b0 found: > Ignoring vsyscall.c (vmlinux) PC=0xff802c9400...0xffff60042a > Choosing lkm.c (lkm.o) PC=0xffa00180c0...0xffa00181d9 > 55 void > 56 lkm_exit(void) > 57 { > 58 printk(KERN_INFO "Exitting LKM (jiffies=%lu)...\n", jiffies); > 59 lkm_func(jiffies); > 60 } > 61 > (gdb) > > OK for mainline? Or should there be a different approach? I'm undecided on whether this patch is a good idea. The best solution would be to replace texthigh/textlow with a data structure representing ranges - Jim's posted some suggestions in the past on how to do this, but it's quite a lot of work. If this patch goes in please add a comment explaining that it is working around bugs in the symtab readers and representation. I don't know how this would affect overlay debugging. I don't suppose any of our simulators are capable of overlays? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer