From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mengyan1223.wang (mengyan1223.wang [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 3EBC93858C52 for ; Tue, 3 May 2022 10:24:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3EBC93858C52 Received: from localhost.localdomain (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@mengyan1223.wang) by mengyan1223.wang (Postfix) with ESMTPSA id 5DCC46656D; Tue, 3 May 2022 06:24:42 -0400 (EDT) Message-ID: Subject: Re: Question related to -fPIC behaviour across architectures From: Xi Ruoyao To: vincent Dupaquis , gcc-help@gcc.gnu.org Date: Tue, 03 May 2022 18:24:40 +0800 In-Reply-To: <7038357f-02af-0bcd-f156-73851c3227b3@trusted-objects.com> References: <7038357f-02af-0bcd-f156-73851c3227b3@trusted-objects.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.1 MIME-Version: 1.0 X-Spam-Status: No, score=-3031.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, KAM_INFOUSMEBIZ, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2022 10:24:46 -0000 On Tue, 2022-05-03 at 10:26 +0200, vincent Dupaquis wrote: > - Is there somewhere a common definition of what mean PIC for the=20 > different architectures ? Generally -fpic/-fPIC does not means only position-independant code, but position-independant code **suitable for dynamic linking**. Consider the code: void callee(void) { /* ... */ } void caller(void) { callee(); } Without -fPIC caller may call callee with a PC-relative call instruction. But with -fPIC it's not allowed because the symbol callee may be interposed. For more info: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic (You may argue that the ELF interposition rule is strange and known to slow down programs, but there are still many programs depending on the rule in 2022.) So my guess is w/o -fPIC the compiler just calls callee with a PC-rel call, but with -fPIC it needs to either: (1) Load the address of callee from GOT. or (2) Call the PLT stub ("callee@PLT") which is resolved to "jump callee" at runtime. For (1), the address of the callee is loaded into a register then a "call register" instruction is used. It seems callx8 is such an instruction on Xtensa (I know nothing about Xtensa so it's from Google). For (2), the compiler and the assembler cannot determine if the PLT stub is out-of-range for the PC-rel call instruction (as the PLT stubs are generated by the linker). So the only approach legal for the worst case is to assume the PLT stub may be far away from the call site. Then a PC-relative address load instruction will be used to load the address of the PLT stub into a register, then callx8 is used to perform the call. For some of other targets, a code model is defined to guarantee the PLT stubs to be in-range of the PC-rel call instruction. Those targets can simply use PC-rel call to invoke callee@PLT. But again I know nothing about Xtensa and I can't reproduce the behavior you mentioned with GCC trunk. It seems always generating "l32r/callx8" pairs for calls on xtensa-linux-gnu, unless the callee is `static`. And it makes sense to me: "l32r", as a PC-relative address loading instruction, will load the address of callee@PLT correctly. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University