From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32006 invoked by alias); 2 Dec 2003 16:18:03 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31982 invoked from network); 2 Dec 2003 16:18:02 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 2 Dec 2003 16:18:02 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1ARDDu-0004LF-87; Tue, 02 Dec 2003 11:18:02 -0500 Date: Tue, 02 Dec 2003 16:18:00 -0000 From: Daniel Jacobowitz To: Kris Warkentin Cc: "Gdb@Sources.Redhat.Com" Subject: Re: Interesting dwarf-2/shared lib problem. Message-ID: <20031202161802.GA16598@nevyn.them.org> Mail-Followup-To: Kris Warkentin , "Gdb@Sources.Redhat.Com" References: <024101c3b8ef$480138c0$0202040a@catdog> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <024101c3b8ef$480138c0$0202040a@catdog> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-12/txt/msg00018.txt.bz2 On Tue, Dec 02, 2003 at 11:13:53AM -0500, Kris Warkentin wrote: > When debugging an app with a shared lib I ran across the following problem. > > After having proceeded to main(), all libs/syms are loaded, source search > directory set appropriately, etc. > > Trying to use the following address form: > > list display.c:10 > -or- > break display.c:27 > > where display.c is in one of the loaded shared libraries, fails with "No > source file named display.c" > > If I then do "break display", where display() is a function in display.c, > the above two addressing forms work fine. > > I observed that libdisplay.so has been loaded with a psymtab and that the > code in lookup_symtab() only searches through objects which have a full > symtab loaded. This would seem to be why it's not finding display.c. I'm > supposing that when you do a break on a function, the full symtab is then > loaded. > > Note also that this goes away if the source is compiled with the stabs+ > debugging format. I'm pondering the solution to this. Is there a way to > force gdb to load the full symbol table for all shared objects? Or is there > a better way to get around this? >From lookup_symtab: /* Same search rules as above apply here, but now we look thru the psymtabs. */ ps = lookup_partial_symtab (name); if (!ps) return (NULL); Is that not working? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer