From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17320 invoked by alias); 20 Jul 2005 17:13:22 -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 17301 invoked by uid 22791); 20 Jul 2005 17:13:17 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 20 Jul 2005 17:13:17 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1DvI8B-0000xK-Py; Wed, 20 Jul 2005 13:13:15 -0400 Date: Wed, 20 Jul 2005 17:13:00 -0000 From: Daniel Jacobowitz To: Paul Koning Cc: gdb@sources.redhat.com Subject: Re: find_pc_partial_function may produce the wrong answer Message-ID: <20050720171315.GA3630@nevyn.them.org> Mail-Followup-To: Paul Koning , gdb@sources.redhat.com References: <17118.24446.528000.56862@gargle.gargle.HOWL> <20050720143326.GA31003@nevyn.them.org> <17118.34095.8510.304158@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17118.34095.8510.304158@gargle.gargle.HOWL> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-07/txt/msg00213.txt.bz2 On Wed, Jul 20, 2005 at 01:09:03PM -0400, Paul Koning wrote: > >>>>> "Daniel" == Daniel Jacobowitz writes: > > Daniel> Is the shared library stripped? I am absolutely positive > Daniel> that the minimal symbol table will include the static symtab > Daniel> - as long as there is one. > > Found the problem. > > The NetBSD build procedure for libraries has a rather peculiar compile > step, which includes running the file through ld with a -x switch. > That will do it... It's not supposed to do that if a -g is present in > the compile options; that may be an error in the top level build > process at our end. Once you've done that, the fact is, a lot of things in GDB are going to go wrong. We assume the presence of minimal symbols in a lot of places. However, most of those places it would be an improvement in GDB to handle only having a function's start represented in the psymtab. > That does leave this puzzle: > > Given such a shared library (no local symbols in the symtab), > "disassemble somestaticfunc" works fine if I open the shared lib > itself with gdb. But if the shared lib is referenced via the shared > lib symbol load machinery, for example because a corefile pointed to > it, then the same disassemble command doesn't work. > > It looks like the code in blockframe.c that pulls in the psymtab to > double-check the function (if an end address was requested) doesn't > work in that second case. Does that make sense? Not really... There shouldn't be any difference. -- Daniel Jacobowitz CodeSourcery, LLC