From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) by sourceware.org (Postfix) with ESMTPS id B5374385743B for ; Thu, 17 Jun 2021 04:24:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B5374385743B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maskray.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-f174.google.com with SMTP id y15so3962437pfl.4 for ; Wed, 16 Jun 2021 21:24:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=VLBj25fNukCX32cGASxIs6xT4CkVcFMPF92q/JYGjCw=; b=uUZDQbVhMDFs+MkKZCc1PvYGUz73vSKiv3hhLPhoTDlmMpvUxf7XFUaim5qNuPT8Ar PjjMd63Aqu9AUvV/KzgOl4bJwjcc41SRx16PlM1p/qGtuB2sDduRrvZcOUoKFcqpktey u911Gv3NSZ/XnHOjnBmiE6o1vqKmy56S6403zXgybvbB6Pjra1HHKWGbxWv138Jg9UuR zXznZLpFBRvlrDZEm5m8xb/XCDl+QSUE9d6c97/PQ+NCQ1xftWga718x0n/VtOFnWSOv KW1jG4SVIZHJ4OQF39He9IxI386UGxGNsB4bqmp2/pzGU6L0n2pLd/sSfoZXLFYXSpHM PRMQ== X-Gm-Message-State: AOAM531PKkY0hplDoT02Cuc0rDnrt75Ym53WFHFDbjYcnlanxymAj/55 pGfOco2fEZnSlk355mX3jaI= X-Google-Smtp-Source: ABdhPJxLZvhCp8+IOQFzMsql98a0/drvlwgUDdmDuUqEfnKWedUK/sVA9vGmQTgNTH0DMR2VqvnKow== X-Received: by 2002:a63:db43:: with SMTP id x3mr3030487pgi.383.1623903845862; Wed, 16 Jun 2021 21:24:05 -0700 (PDT) Received: from localhost ([2601:647:4b01:ae80:fa3e:eeb6:1e91:d40d]) by smtp.gmail.com with ESMTPSA id o139sm3792943pfd.96.2021.06.16.21.24.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Jun 2021 21:24:05 -0700 (PDT) Date: Wed, 16 Jun 2021 21:24:04 -0700 From: Fangrui Song To: Alan Modra Cc: Cary Coutant , "H.J. Lu" , Michael Matz , Florian Weimer , Szabolcs Nagy , "binutils@sourceware.org" , Fangrui Song Subject: Re: [PATCH] Allow direct access relocations referencing a protected function symbol Message-ID: <20210617042404.cdojdbmlage6bw7y@gmail.com> References: <20210614174336.4g4gesqc6nxnmho4@gmail.com> <20210615031932.i4g36e4bmwplsgoi@gmail.com> <20210616044217.6coujfcfpvz2de5h@gmail.com> <20210616081143.befkfjzdqvybjpbz@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_INFOUSMEBIZ, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 04:24:08 -0000 On 2021-06-17, Alan Modra wrote: >On Wed, Jun 16, 2021 at 01:11:43AM -0700, Fangrui Song wrote: >> While (I think Cary/Michael) and I prefer that STV_PROTECTED STT_FUNC symbols don't have unneeded dynamic relocations in -shared mode, > >I strongly prefer that too. The only thing I object to is incorrect >fixes.. Thanks... >> I don't mind if GNU ld keeps producing them. >> Anyhow the important thing is the following spurious error: >> >> % gcc -fpic -shared -fuse-ld=bfd a.s >> /usr/bin/ld.bfd: /tmp/ccWPJCLw.o: relocation R_X86_64_PC32 against protected symbol `foo' can not be used when making a shared object >> __attribute__((visibility("protected"))) void *foo () { >> return (void *)foo; >> } > >Agreed, that is an x86 linker bug. Sent https://sourceware.org/pipermail/binutils/2021-June/116985.html for x86-64. Hope some aarch64 folks in the CC list can fix aarch64... >Here is the result of your testcase on powerpc64le, power10 to get >pc-relative cpu support, and linked without startup files so just the >relocs in this code are seen. > >powerpc64le-linux-gcc -c -O2 -fPIC -mcpu=power10 prot2.c >powerpc64le-linux-ld -shared -o prot2 prot2.o >readelf -r prot2 >There are no relocations in this file. So x86 and aarch64 have major issues. arm has a minor issue. other ports are probably good. x86-64: broken direct access relocation, unneeded GLOB_DAT aarch64: broken direct access relocation, unneeded GLOB_DAT arm: unneeded GLOB_DAT ppc64le: good mips64el: good riscv64: good >> >> If you decide to take over, fixing the error will be really great and will be an important step fixing protected symbols. > >It would be inappropriate for me to take over. This is a target >issue, caused by a deliberate choice on the part of HJ to optimise in >the executable at the expense of shared library optimisation (*). The >fix needs to be in the x86 target code, and it's a very long time >since I was an x86 binutils maintainer. nvm, I sent https://sourceware.org/pipermail/binutils/2021-June/116985.html >*) I'll note that at the time, when non-pic executables were more >common, the trick HJ used made quite a lot of sense from an >optimisation viewpoint, but frankly I'm amazed that he managed to get >it all working. In fact, the optimisation makes even more sense on >powerpc prior to power10 but I was unwilling to go against the ELF >gABI (when narrowly considering the resulting shared libraries in >isolation) just to shave off cycles in micro-benchmarks. Hmm, I think those changes don't improve -fno-pic or -fpie performance. ELF -fno-pic has always been using absolute relocations for data/functions. For -fpie, HAVE_LD_PIE_COPYRELOC has no benefit but a tiny bit of size decrease. ppc64 ELFv2 toc-indirection to toc-relative optimization renders the GOT optimization mostly useless, as well. HAVE_LD_PIE_COPYRELOC, if implemented, may have a tiny bit of effects on other arches, but I am of the opinion that toolchain developers do not necessarily show mercy to applications where global variable access is a bottleneck. The applications should fix their global variable usage: hidden/protected/local alias. Either can improve global variable access if they indeed decide to care. Unfortunately protected data accesses have unneeded GOT indirection for all GCC arches in -fpic mode.