From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id 6DF8E3851C2E for ; Sat, 26 Dec 2020 15:31:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6DF8E3851C2E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fw@deneb.enyo.de Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ktBXo-00059Z-WF; Sat, 26 Dec 2020 15:31:49 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1ktBXo-00021e-Qe; Sat, 26 Dec 2020 16:31:48 +0100 From: Florian Weimer To: Fangrui Song Cc: gcc@gcc.gnu.org Subject: Re: Add -fdirect-access-external-data References: <20201217071017.xylpud62keerb54u@gmail.com> Date: Sat, 26 Dec 2020 16:31:48 +0100 In-Reply-To: <20201217071017.xylpud62keerb54u@gmail.com> (Fangrui Song's message of "Wed, 16 Dec 2020 23:10:17 -0800") Message-ID: <87h7o81t3v.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2020 15:31:53 -0000 * Fangrui Song: > Hi, I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 which > proposes -fdirect-access-external-data to address some x86-64 > GCC/binutils pain[1] and also benefit non-x86 architectures (also see [1] > it can prevent copy relocations). > > [1] Mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112#c2 > > Since I am going to add this option to Clang and I hope (once GCC decides to > implement this option the two compilers can use the same option name), I bring > it to your attention. One worry I have is that people start building shared objects with direct data access, expecting the main program to be built with indirect access. We already see this today with Qt. It's not really supported well by the toolchain and causes frequent issues. Depending on the ELF ABI in question, the new pair of -f options might not actually be meaningful. It really depends on whether you have reasonably-sized displacements available. I think there are some ABIs where the optimization is theoretically possible, but impractical because the ilimit it imposes on data segment (think AArch64 without adrp).