From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id CB5F33853D67 for ; Thu, 17 Nov 2022 17:30:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CB5F33853D67 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B54BF23A; Thu, 17 Nov 2022 09:30:24 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ACEB53F73B; Thu, 17 Nov 2022 09:30:17 -0800 (PST) From: Richard Sandiford To: Wilco Dijkstra Mail-Followup-To: Wilco Dijkstra ,GCC Patches , Kyrylo Tkachov , "maskray\@google.com" , richard.sandiford@arm.com Cc: GCC Patches , Kyrylo Tkachov , "maskray\@google.com" Subject: Re: [PATCH] AArch64: Add support for -mdirect-extern-access References: Date: Thu, 17 Nov 2022 17:30:16 +0000 In-Reply-To: (Wilco Dijkstra's message of "Thu, 17 Nov 2022 16:42:01 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-34.8 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Wilco Dijkstra writes: > Hi Richard, > >> Can you go into more detail about: >> >> Use :option:`-mdirect-extern-access` either in shared libraries or in >> executables, but not in both. Protected symbols used both in a shared >> library and executable may cause linker errors or fail to work correctly >> >> If this is LLVM's default for PIC (and by assumption shared libraries), >> is it then invalid to use -mdirect-extern-access for any PIEs that >> are linked against those shared libraries and use protected symbols >> from those libraries? How would a user know that one of the shared >> libraries they're linking against was built in this way? > > Yes, the usage model is that you'd either use it for static PIE or only on > data that is not shared. If you get it wrong them you'll get the copy > relocation error. Thanks. I think I'm still missing something though. If, for the non-executable case, people should only use the feature on data that is not shared, why do we need to relax the binds-local condition for protected symbols on -fPIC? Oughtn't the symbol to be hidden rather than protected if the data isn't shared? I can understand the reasoning for the PIE changes but I'm still struggling with the PIC-but-not-PIE bits. > In the future we need to decide what the ABI is and > ensure GCC and LLVM are compatible. An import feature to mark symbols > that may be overridden by a shared library would be useful too. > >> It looks like the main difference between this implementation and >> the x86 one is that x86 allows direct accesses to common symbols. >> What's the reason for not doing that for AArch64? Does it not work, >> is it a false optimisation (i.e. pessimisation), or did it not seem >> important now that -fno-common is the default? > > I don't see any difference in the way common symbols are accessed on x86, > so it's not clear which cases common_local_p param actually affects (eg. with > -fPIC there is always a GOT indirection for common symbols). Hmm, OK. Could it be for one of the other languages? But yeah, if we don't have a testcase for it, I agree it's better to leave things as they are. Thanks, Richard