From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2947 invoked by alias); 16 Nov 2005 01:33:32 -0000 Received: (qmail 2934 invoked by uid 22791); 16 Nov 2005 01:33:30 -0000 Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.193) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 16 Nov 2005 01:33:30 +0000 Received: by zproxy.gmail.com with SMTP id l1so1946878nzf for ; Tue, 15 Nov 2005 17:33:28 -0800 (PST) Received: by 10.36.250.70 with SMTP id x70mr3548261nzh; Tue, 15 Nov 2005 17:33:28 -0800 (PST) Received: by 10.37.2.35 with HTTP; Tue, 15 Nov 2005 17:33:28 -0800 (PST) Message-ID: <8f2776cb0511151733l3fe56256w22954ac8ba9afa7b@mail.gmail.com> Date: Wed, 16 Nov 2005 01:33:00 -0000 From: Jim Blandy To: Jim Blandy , Ron McCall , gdb@sources.redhat.com Subject: Re: warning: (Internal error: pc 0xd00 in read in psymtab, but not in symtab.) In-Reply-To: <20051116003812.GA25895@nevyn.them.org> 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> <8f2776cb0511151510p1d7fe81dl7aa7a6b439b4622@mail.gmail.com> <20051115232518.GA24754@nevyn.them.org> <8f2776cb0511151612g34ce97ccn9a6b5101615b49f5@mail.gmail.com> <20051116003812.GA25895@nevyn.them.org> 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/msg00308.txt.bz2 On 11/15/05, Daniel Jacobowitz wrote: > > When we drop a linkonce section, we also drop all relocs referring to > > symbols defined in that section, or the section's STT_SECTION symbol. > > (Or do we just make the relocs use STN_UNDEF as their symbol?) If the > > Neither, quite. We specifically fail to resolve them because they are > in .debug_info; otherwise this would be a fatal error. Do we need some sort of annotation in the debug information itself, indicating that it's referring to stuff that might go away? Suppose we had a new reloc type, generic name BFD_RELOC_SECTION_INCLUDED, whose symbol must be an STT_SECTION symbol. The reloc refers to a single byte which the linker should set to one if the symbol's section is present in the resulting object, or zero if it has been dropped. Then the appropriate dies could have a DW_AT_GNU_section_included attribute, DW_FORM_flag, whose operand had that reloc applied to it. The compiler's chopping the program up into these sections; make it responsible for telling us what debug info corresponds to what code. Ideally, the debug info itself would just get edited, but I'm not sure how we would go about that.