From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id 9B15D38362DB for ; Thu, 1 Sep 2022 02:09:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9B15D38362DB Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from [10.20.4.152] (unknown [10.20.4.152]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Bx5OFNFBBjJ2MOAA--.63381S3; Thu, 01 Sep 2022 10:09:17 +0800 (CST) Subject: Re: [PATCH] LoongArch: Use copy relocation for %pc_lo12 against external symbol To: Xi Ruoyao , binutils@sourceware.org Cc: WANG Xuerui , chenglulu@loongson.cn References: <20220831132259.71417-1-xry111@xry111.site> From: liuzhensong Message-ID: <5bafc296-022f-7b77-5ce4-00b09fee56f9@loongson.cn> Date: Thu, 1 Sep 2022 10:09:16 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8Bx5OFNFBBjJ2MOAA--.63381S3 X-Coremail-Antispam: 1UD129KBjvdXoW7Jr4rAFW5KFWxuFWrtFWUJwb_yoWfuFX_ur W8Gr1xCw1UJr4xAFn8tFZ7AryrJFs09rWUta4vgr43Ga43Xry5CrWkC3s5t3ZIqFyfJF9x Cr4fJ3s5t347ujkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbI8YjsxI4VWkKwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAC Y4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJV W8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07AlzVAYIcxG 8wCY02Avz4vE-syl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxV Aqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r12 6r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AK xVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvj xUgg_TUUUUU X-CM-SenderInfo: holx6xphqv003j6o00pqjv00gofq/ X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,NICE_REPLY_A,SCC_BODY_URI_ONLY,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: 在 2022/9/1 上午9:41, Xi Ruoyao 写道: > On Thu, 2022-09-01 at 09:27 +0800, liuzhensong wrote: > >> The R_LARCH_COPY is supported in older versions, we removed this >> feature and are not going to support. > Hmm, then for > > extern int x; > int f() { return x; } > > it will produce a GOT access. If x is in another TU but not in a shared > library, such a GOT access and the GOT entry is unneeded. > > This will be really a pain for situations like building an OS kernel, or > with -static or -static-pie. Even for this simple example, there is no > way to tell "x" is not in a shared library (maybe, expect LTO or linker > relaxation, but IIRC LTO or relaxation do not *guarantee* to avoid the > GOT, just "try to" avoid the GOT). > > So is there any serious reason forbidding us from using R_LARCH_COPY? Or > any options for this "unneeded GOT" issue? https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected