From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28341 invoked by alias); 22 Aug 2008 17:17:50 -0000 Received: (qmail 28331 invoked by uid 22791); 22 Aug 2008 17:17:49 -0000 X-Spam-Check-By: sourceware.org Received: from are.twiddle.net (HELO are.twiddle.net) (75.149.56.221) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 22 Aug 2008 17:17:15 +0000 Received: from stone.twiddle.home (stone.twiddle.home [172.31.0.4]) by are.twiddle.net (Postfix) with ESMTP id 9ECDF57576; Fri, 22 Aug 2008 10:17:13 -0700 (PDT) Message-ID: <48AEF499.8020509@twiddle.net> Date: Fri, 22 Aug 2008 17:53:00 -0000 From: Richard Henderson User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: John David Anglin CC: sje@cup.hp.com, gcc-patches@gcc.gnu.org, dave.anglin@nrc-cnrc.gc.ca Subject: Re: update dwarf2 asm unwind info [hppa64-*-* failures] References: <20080822001442.623294E2A@hiauly1.hia.nrc.ca> In-Reply-To: <20080822001442.623294E2A@hiauly1.hia.nrc.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-08/txt/msg01693.txt.bz2 John David Anglin wrote: >> I don't suppose the HP linker supports R_PARISC_SEGREL32 at >> an unaligned address? If so, you could fairly easily arrange >> to use DW_EH_PE_textrel as the encoding for the function addrs. > > Don't know but I doubt it. I would expect the situation is the > same as for ia64. > > It is possible that pc-relative relocations might work if .eh_frame > was read-only for hppa64. I have checked and found that plabels can > be in a read-only in both executables and shared libraries. However, > I'm still not sure that the EH processing will work for shared > libraries. Also, putting the EH data in a read-only section would > probably break existing code. I wasn't considering making the EH data read-only, I was only considering reducing the number of dynamic relocations needed. At present, the absolute addresses mean that you need dynamic fixups for shared libraries, and for executables when the segments used aren't what the static linker selected. If segment-relative relocations were used, you'd only have one dynamic relocation -- the one that records the base of the segment in __register_frame_info_bases. r~