From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13868 invoked by alias); 2 Dec 2003 16:49:44 -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 13861 invoked from network); 2 Dec 2003 16:49:43 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 2 Dec 2003 16:49:43 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id MAA13127; Tue, 2 Dec 2003 12:02:32 -0500 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id LAA16720; Tue, 2 Dec 2003 11:49:42 -0500 Message-ID: <025701c3b8f4$6e1cfb70$0202040a@catdog> From: "Kris Warkentin" To: "Daniel Jacobowitz" Cc: "Gdb@Sources.Redhat.Com" References: <024101c3b8ef$480138c0$0202040a@catdog> <20031202161802.GA16598@nevyn.them.org> Subject: Re: Interesting dwarf-2/shared lib problem. Date: Tue, 02 Dec 2003 16:49:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-SW-Source: 2003-12/txt/msg00019.txt.bz2 > > 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? Ah...interesting. For the main object, the symtab points to c:\some_dir\main.c and the symtab->next points to just main.c. It's the main.c that gets caught and returned. In the solib, we only see the c:\some_lib\display.c so the FILENAME_CMP fails.. So you are correct, lookup_partial_symtab is failing. cheers, Kris