From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23707 invoked by alias); 5 Nov 2004 20:53:56 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23696 invoked from network); 5 Nov 2004 20:53:55 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 5 Nov 2004 20:53:55 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id iA5Krllo023556; Fri, 5 Nov 2004 21:53:47 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id iA5KrlZ6014742; Fri, 5 Nov 2004 21:53:47 +0100 (CET) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id iA5KrgYS014739; Fri, 5 Nov 2004 21:53:42 +0100 (CET) Date: Fri, 05 Nov 2004 20:53:00 -0000 Message-Id: <200411052053.iA5KrgYS014739@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: cagney@gnu.org, gdb-patches@sources.redhat.com In-reply-to: <20041105204101.GA23606@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 5 Nov 2004 15:41:02 -0500) Subject: Re: [COMMIT] Fix decoding CIE's in DWARF frame info References: <200411051543.iA5Fh1nK020633@juw15.nfra.nl> <418BB19C.7000100@gnu.org> <200411051853.iA5IrpfP014435@elgar.sibelius.xs4all.nl> <20041105191217.GA23973@nevyn.them.org> <200411052036.iA5KaHFK014692@elgar.sibelius.xs4all.nl> <20041105204101.GA23606@nevyn.them.org> X-SW-Source: 2004-11/txt/msg00093.txt.bz2 Date: Fri, 5 Nov 2004 15:41:02 -0500 From: Daniel Jacobowitz > I don't think so. We read the encoded pointers when we load the > executable in GDB. But if the value of these encoded pointers is > known at that point, why doesn't the (static) linker resolve things > instead of having us goe through the indirection process? Because this is used, as far as I know, only for PIC code in shared libraries (which we only load after they've been dynamically relocated). DW_EH_PE_indirect is used so that symbols which will need a runtime RELATIVE relocation live in the data segment, instead of the with the rest of the exception data, which could otherwise be read-only. Hmm. You might be right. Didn't think about it that way. Mark