From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12483 invoked by alias); 15 Nov 2005 23:10:57 -0000 Received: (qmail 12460 invoked by uid 22791); 15 Nov 2005 23:10:54 -0000 Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.197) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 15 Nov 2005 23:10:54 +0000 Received: by zproxy.gmail.com with SMTP id l1so1913751nzf for ; Tue, 15 Nov 2005 15:10:52 -0800 (PST) Received: by 10.36.59.8 with SMTP id h8mr5706017nza; Tue, 15 Nov 2005 15:10:52 -0800 (PST) Received: by 10.37.2.35 with HTTP; Tue, 15 Nov 2005 15:10:52 -0800 (PST) Message-ID: <8f2776cb0511151510p1d7fe81dl7aa7a6b439b4622@mail.gmail.com> Date: Tue, 15 Nov 2005 23:10:00 -0000 From: Jim Blandy To: Ron McCall Subject: Re: warning: (Internal error: pc 0xd00 in read in psymtab, but not in symtab.) Cc: gdb@sources.redhat.com In-Reply-To: <20051115204629.32845.qmail@web81206.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051115204629.32845.qmail@web81206.mail.mud.yahoo.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00300.txt.bz2 On 11/15/05, Ron McCall wrote: > I applied your patch to a pristine copy of gdb 6.3 and > rebuilt and sure enough, that makes the warning go > away! Should this patch get into the "real" gdb > sources? No; take a look at the comment above one of the sections commented out by the patch: /* When using the GNU linker, .gnu.linkonce. sections are used to eliminate duplicate copies of functions and vtables and such. The linker will arbitrarily choose one and discard the others. The AT_*_pc values for such functions refer to local labels in these sections. If the section from that file was discarded, the labels are not in the output, so the relocs get a value of 0. If this is a discarded function, mark the pc bounds as invalid, so that GDB will ignore it. */ Fixing this entails some more reliable method of recognizing debug info referring to functions or variables in deleted sections than what we have now. Perhaps one of our linker fanatics knows of the Right Way? One possibility might be to tighten up the heuristic. Presumably, if a function's low address is at zero because the function is really located at the bottom of the address space, then its high address won't be zero. But if the function was deleted, both the high and low PC will be zero.