From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26128 invoked by alias); 10 Jan 2007 04:16:45 -0000 Received: (qmail 26120 invoked by uid 22791); 10 Jan 2007 04:16:45 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 10 Jan 2007 04:16:40 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H4UtB-0004F4-OI; Tue, 09 Jan 2007 23:16:37 -0500 Date: Wed, 10 Jan 2007 04:16:00 -0000 From: Daniel Jacobowitz To: Sandeep Joshi Cc: gdb@sourceware.org Subject: Re: GDB not able to debug files(dwarf2.0) loaded using add-symbol-file Message-ID: <20070110041637.GD14719@nevyn.them.org> Mail-Followup-To: Sandeep Joshi , gdb@sourceware.org References: <20061223212620.GC1091@nevyn.them.org> <20070104033008.GA2223@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) 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-01/txt/msg00164.txt.bz2 On Thu, Jan 04, 2007 at 12:26:51PM +0530, Sandeep Joshi wrote: > Here the pc to be looked is is '34148' . It starts with first object > file i.e vmlinux and checks all the psymtabs for their code range. Now > for the above psymtab, Code range is 'textlow = 288, texthigh = > 1076066628' and our PC lies in this. So this is set as best_pst and > function returns without checking the second objfile, which has the > perfect match for this PC. That is why gdb is not able to show the > sources correct. Aha. OK, this is actually a different bug - the range should be set that way. Unfortunately, this is a very hard bug to fix in GDB. I recently patched GNU ld to prevent this from happening in new releases; the patch is here: http://sourceware.org/ml/binutils/2006-11/msg00019.html If you can apply that to your linker, I believe it will fix up the problem, which comes from /DISCARD/ { *(.text.exit) } in the kernel's linker scripts. If you can't change your linker, it should be possible to detect the problem in GDB. Where we currently check for has_section_at_zero, in dwarf2read.c, check instead that the address is in some section in the file. -- Daniel Jacobowitz CodeSourcery