From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5457 invoked by alias); 20 Jul 2005 14:28:26 -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 5359 invoked by uid 22791); 20 Jul 2005 14:28:18 -0000 Received: from sadr.equallogic.com (HELO sadr.equallogic.com) (66.155.203.134) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 20 Jul 2005 14:28:18 +0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j6KESGZZ031197 for ; Wed, 20 Jul 2005 10:28:16 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j6KESFNd031192 for ; Wed, 20 Jul 2005 10:28:15 -0400 Received: from PKONING.equallogic.com ([172.16.1.186]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Jul 2005 10:28:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17118.24446.528000.56862@gargle.gargle.HOWL> Date: Wed, 20 Jul 2005 14:28:00 -0000 From: Paul Koning To: gdb@sources.redhat.com Subject: find_pc_partial_function may produce the wrong answer X-SW-Source: 2005-07/txt/msg00207.txt.bz2 I was tracking down a problem in my (modified) gdb, which showed up when doing callstack tracing by reading the prologue. (mips-tdep can do that, and in my version it does it most of the time.) The problem is that find_pc_partial_function is used to find the start of the function, and it was producing the wrong answer. Specifically, it produces the wrong answer when the function is in a shared library. The cause of the problem is that find_pc_partial_function looks up the symbol in the msymtab, and that contains only external symbols, not static symbols. The comments in the source code explicitly claim that it DOES contain static symbols, but "maint print msymtab" clearly shows that it doesn't. At least not for MIPS shared libraries... I noticed the disassemble command calls the same function, so I checked why it seemed to be ok. The difference is that it passes a pointer to the end_address argument, and that forces the psymtab to be read which has the right answer. Well, that's not the whole workaround either. "disassemble" works correctly if you just open the shared library ("file usr/lib/libc.so"). But it too does the wrong thing -- starts disassembling at the previous non-static function start -- when the function is in a shared library that's mapped when you open the corefile, via the "set solib-absolute-prefix" machinery. Help? paul