From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-23234-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 30887 invoked by alias); 16 Nov 2005 00:12:17 -0000
Received: (qmail 30873 invoked by uid 22791); 16 Nov 2005 00:12:15 -0000
Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.197)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 16 Nov 2005 00:12:15 +0000
Received: by zproxy.gmail.com with SMTP id l1so1926041nzf
        for <gdb@sources.redhat.com>; Tue, 15 Nov 2005 16:12:14 -0800 (PST)
Received: by 10.36.3.15 with SMTP id 15mr5759637nzc;
        Tue, 15 Nov 2005 16:12:14 -0800 (PST)
Received: by 10.37.2.35 with HTTP; Tue, 15 Nov 2005 16:12:14 -0800 (PST)
Message-ID: <8f2776cb0511151612g34ce97ccn9a6b5101615b49f5@mail.gmail.com>
Date: Wed, 16 Nov 2005 00:12:00 -0000
From: Jim Blandy <jimb@red-bean.com>
To: Jim Blandy <jimb@red-bean.com>, Ron McCall <ronald.mccall@snet.net>, 
	gdb@sources.redhat.com
Subject: Re: warning: (Internal error: pc 0xd00 in read in psymtab, but not in symtab.)
In-Reply-To: <20051115232518.GA24754@nevyn.them.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <dlc0b4$ic3$1@sea.gmane.org>
	 <20051115204629.32845.qmail@web81206.mail.mud.yahoo.com>
	 <8f2776cb0511151510p1d7fe81dl7aa7a6b439b4622@mail.gmail.com>
	 <20051115232518.GA24754@nevyn.them.org>
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2005-11/txt/msg00304.txt.bz2

On 11/15/05, Daniel Jacobowitz <drow@false.org> wrote:
> No, that doesn't work.  The high address is probably
> .gnu.linkonce.foo+0x104, which may show up as 0x104 depending on the
> relocation format in use.

Checking my understanding:

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.=20
(Or do we just make the relocs use STN_UNDEF as their symbol?)  If the
architecture uses RELA relocs, then there's probably a zero sitting in
the code itself, but if it uses REL, then the addend is in the code,
so we'll see it when we read the value in GDB.