From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33417 invoked by alias); 23 Sep 2019 08:37:34 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 33395 invoked by uid 89); 23 Sep 2019 08:37:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=unavailable version=3.3.1 spammy= X-HELO: mailout.enyo.de Received: from mailout.enyo.de (HELO mailout.enyo.de) (116.203.30.208) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 23 Sep 2019 08:37:32 +0000 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iCJqb-0002Ty-KQ; Mon, 23 Sep 2019 08:37:29 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1iCJqb-0007NU-Hq; Mon, 23 Sep 2019 10:37:29 +0200 From: Florian Weimer To: Alan Modra Cc: binutils@sourceware.org, libc-alpha@sourceware.org, gcc@gcc.gnu.org Subject: Re: POWER PC-relative addressing and new text relocations References: <87o8zbcvb7.fsf@mid.deneb.enyo.de> <20190923083122.GC3685@bubble.grove.modra.org> Date: Mon, 23 Sep 2019 08:37:00 -0000 In-Reply-To: <20190923083122.GC3685@bubble.grove.modra.org> (Alan Modra's message of "Mon, 23 Sep 2019 18:01:22 +0930") Message-ID: <87impjcss6.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00188.txt.bz2 * Alan Modra: > On Mon, Sep 23, 2019 at 09:42:52AM +0200, Florian Weimer wrote: >> At Cauldron, the question came up whether the dynamic loader needs to >> be taught about the new relocations for PC-relative addressing. >> >> I think they would only matter if we supported PC-relative addressing >> *and* text relocations. Is that really necessary? >> >> These text relocations would not work reliably anyway because the >> maximum displacement is not large enough. For example, with the >> current process layout, it's impossible to reach shared objects from >> the main program and vice versa. And some systems might want to add >> additional randomization, so that shared objects are not mapped closed >> together anymore. > > We've been discussing this inside IBM too. The conclusion is that > only one of the new relocs makes any possible sense as a dynamic > reloc, R_PPC64_TPREL34, and that one only if you allow > -ftls-model=local-exec when building shared libraries and accept that > DF_STATIC_TLS shared libraries that can't be dlopen'd are OK. Is this still a text relocation? The displacement relative to the thread pointer is (usually) small, so I can see how this could work reliable. What's the restriction on dlopen? Wouldn't it be the same as regular initial-exec TLS memory, which also uses static TLS, but without a text relocation and an additional indirection to load the TLS offset from a place where a regular relocation has put it?