From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 15118 invoked from network); 17 Apr 2020 10:58:51 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 17 Apr 2020 10:58:51 -0000 Received: (qmail 14031 invoked by uid 550); 17 Apr 2020 10:58:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 14010 invoked from network); 17 Apr 2020 10:58:48 -0000 From: Florian Weimer To: Rich Felker Cc: musl@lists.openwall.com References: <20200226052448.GA2769@voyager> <20200226173621.GA11469@brightrain.aerifal.cx> <87a7556vo8.fsf@mid.deneb.enyo.de> <20200226190042.GB11469@brightrain.aerifal.cx> <874kvd6s80.fsf@mid.deneb.enyo.de> <20200226224820.GD11469@brightrain.aerifal.cx> Date: Fri, 17 Apr 2020 12:58:35 +0200 In-Reply-To: <20200226224820.GD11469@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 26 Feb 2020 17:48:20 -0500") Message-ID: <873692crac.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [musl] [PATCH] Add REL_COPY size change detection * Rich Felker: >> If I recall correctly, the optimization was a factor when rolling out >> PIE-by-default in Fedora. I do not know if we can revert it without >> switching back to fixed-address builds. > > I think this is almost surely premature optimization. In almost all > cases, if there's software where the performance impact makes a > difference it can be avoided by giving the affected global data > objects visibility of hidden (if it's not used outside the main > program anyway) or protected (if it needs to be externally visible). > But on x86_64 and aarch64, and to some extent on 32-bit arm as well, > the performance difference of accessing globals via the got vs > pc-relative is negligible. I think the main obstacle is that we do not have the required annotations in the header files. LTO only for deciding whether calls are local or not could perhaps solve this. >> There is also a similar truncation issue for TLS variables, I think. > > TLS variables never use copy relocations, except for a short period of > time on riscv64, where thankfully it was realized to be a mistake and > reverted. So I don't think this issue applies to TLS. You are right, the optimization I feared is not actually implemented.