From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72680 invoked by alias); 23 Sep 2019 10:01:18 -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 66866 invoked by uid 89); 23 Sep 2019 10:01:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=accident, theory, HX-Languages-Length:1824 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 10:01:10 +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 1iCL9W-0005Mn-5I; Mon, 23 Sep 2019 10:01:06 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1iCL9O-0000V7-Rd; Mon, 23 Sep 2019 12:00:58 +0200 From: Florian Weimer To: Alan Modra Cc: binutils@sourceware.org, libc-alpha@sourceware.org, gcc@gcc.gnu.org, Tulio Magno Quites Machado Filho Subject: Re: POWER PC-relative addressing and new text relocations References: <20190923095305.GE3685@bubble.grove.modra.org> Date: Mon, 23 Sep 2019 10:01:00 -0000 In-Reply-To: <20190923095305.GE3685@bubble.grove.modra.org> (Alan Modra's message of "Mon, 23 Sep 2019 19:23:05 +0930") Message-ID: <8736gnbacl.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00192.txt.bz2 * Alan Modra: > On Mon, Sep 23, 2019 at 11:14:12AM +0200, Florian Weimer wrote: >> * Alan Modra: >> >> > On Mon, Sep 23, 2019 at 10:37:29AM +0200, Florian Weimer wrote: >> >> * Alan Modra: >> >> >> >> > On Mon, Sep 23, 2019 at 09:42:52AM +0200, Florian Weimer wrote: >> >> > 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? >> > >> > Yes. I should have mentioned that too. >> >> Yuck. Is this *really* necessary? > > The idea was to allow lusers to do the same as they can on other > architectures, to minimise the number of bug reports saying "but I can > do this on x86". > > Hmm, I just checked. > $ gcc -shared -fPIC -ftls-model=local-exec -o thread.so ~/src/tmp/thread.c > /usr/bin/ld: /tmp/ccoXMrxD.o: relocation R_X86_64_TPOFF32 against > symbol `p' can not be used when making a shared object; recompile with > -fPIC It works with -m32. In theory, we still have DT_TEXTREL support for x86-64 in the loader, but I think BFD ld at least does not really support it. Since x86-64 only has 32-bit displacements, text relocations suffer from similar limitations as they would on POWER, so this looks to me mostly like a historical accident (like the existing text relocations that are recognized by the loader on POWER ELFv2). Going forward, I'll assume that we won't need any loader changes on POWER, and will not promote text relocations, either. It's nice that there isn't something left to do for us for once.