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 2740338362CF for ; Thu, 1 Sep 2022 01:38:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2740338362CF 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 AQAAf8DxPGsmDRBjoV8OAA--.1761S3; Thu, 01 Sep 2022 09:38:46 +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: <3b43c733-6011-8c7c-4a1e-3faa9f91f711@loongson.cn> Date: Thu, 1 Sep 2022 09:38:46 +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-Language: en-US X-CM-TRANSID: AQAAf8DxPGsmDRBjoV8OAA--.1761S3 X-Coremail-Antispam: 1UD129KBjvJXoWxJr4DZw4UKw1fuF4kJry5Jwb_yoW8ZFWDpr 18Jr1jgrWkJr1fJr1UCryUZ345Gr48Jw1UG3W8J3WUXry7Jryjqrn0qrWj9w1UJr4xJr4U Zr1UtryxZ3W5A3JanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487McIj6xII jxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IY64vIr41l7480Y4vEI4kI2Ix0rVAqx4xJMxk0xIA0c2IEe2xFo4CEbIxvr21l c2xSY4AK6svPMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I 8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWU twCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x 0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_ Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUqr -PUUUUU X-CM-SenderInfo: holx6xphqv003j6o00pqjv00gofq/ X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, BODY_8BITS, HTML_MESSAGE, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2022 01:38:51 -0000 在 2022/8/31 下午9:41, Xi Ruoyao 写道: > Some self review: > > On Wed, 2022-08-31 at 21:22 +0800, Xi Ruoyao wrote: >> -             /* For pcalau12i + jirl.  */ >> -             h->needs_plt = 1; >> -             if (h->plt.refcount < 0) >> -               h->plt.refcount = 0; >> -             h->plt.refcount++; >> +             /* Check if it's a jirl instruction.  */ >> +             bfd_byte *contents = elf_section_data (sec)->this_hdr.contents; >> +             uint32_t insn = 0; >> + >> +             if (contents || bfd_malloc_and_get_section (abfd, sec, &contents)) >> +               memcpy(&insn, contents + rel->r_offset, sizeof(insn)); >> + >> +             if ((insn & 0xfc000000) == 0x4c000000) > This is tricky. But in commit 42bd525 we already started to rely on > undocumented %pc_{hi20,lo12} behavior: if you just apply them "as > documented" to the pcalau12i/jirl pairs the result will be absolutely > wrong. And 42bd525 behavior is not fully correct: if you just write > > pcalau12i $t0, %pc_hi20(data) > ld.d, $t0, $t0, %pc_lo12(data) Do you have a test case? > > With 42bd525, the BFD linker generates a "PLT for data" (absolutely > nonsense), and destroys the ld.d instruction. All of these buggy > behavior happens silently, the user will only find something wrong when > the linked program crashes. > > I'm not sure if checking JIRL (i. e. the behavior of a relocation now > depends on the instruction where it's applied) is a good idea. Maybe we > should use the following instead of pcalau12i/jirl: > > pcaddu18i $t0, %b16_hi20(func) > jirl $ra, $t0, %b16(func) > > ("b16_hi20" is a hypothetical thing here.) This will make things less > tricky, and also expand the range to 128 GiB. It doesn't make sense for only "pcaddu18i + jirl" to access 128G.What we need is a jump that can access ±2G, just like any other pc-relative instructions can access ±2G. 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 2740338362CF for ; Thu, 1 Sep 2022 01:38:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2740338362CF 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 AQAAf8DxPGsmDRBjoV8OAA--.1761S3; Thu, 01 Sep 2022 09:38:46 +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: <3b43c733-6011-8c7c-4a1e-3faa9f91f711@loongson.cn> Date: Thu, 1 Sep 2022 09:38:46 +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: multipart/alternative; boundary="------------DE277EC6956739E63FBAB061" Content-Language: en-US X-CM-TRANSID:AQAAf8DxPGsmDRBjoV8OAA--.1761S3 X-Coremail-Antispam: 1UD129KBjvJXoWxJr4DZw4UKw1fuF4kJry5Jwb_yoW8ZFWDpr 18Jr1jgrWkJr1fJr1UCryUZ345Gr48Jw1UG3W8J3WUXry7Jryjqrn0qrWj9w1UJr4xJr4U Zr1UtryxZ3W5A3JanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487McIj6xII jxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IY64vIr41l7480Y4vEI4kI2Ix0rVAqx4xJMxk0xIA0c2IEe2xFo4CEbIxvr21l c2xSY4AK6svPMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I 8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWU twCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x 0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_ Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUqr -PUUUUU X-CM-SenderInfo: holx6xphqv003j6o00pqjv00gofq/ X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,BODY_8BITS,HTML_MESSAGE,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Message-ID: <20220901013846.SfjWQdSfsD84gJbn26f79lcS1dWuoBLMh3kt8pl0w00@z> This is a multi-part message in MIME format. --------------DE277EC6956739E63FBAB061 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 在 2022/8/31 下午9:41, Xi Ruoyao 写道: > Some self review: > > On Wed, 2022-08-31 at 21:22 +0800, Xi Ruoyao wrote: >> -             /* For pcalau12i + jirl.  */ >> -             h->needs_plt = 1; >> -             if (h->plt.refcount < 0) >> -               h->plt.refcount = 0; >> -             h->plt.refcount++; >> +             /* Check if it's a jirl instruction.  */ >> +             bfd_byte *contents = elf_section_data (sec)->this_hdr.contents; >> +             uint32_t insn = 0; >> + >> +             if (contents || bfd_malloc_and_get_section (abfd, sec, &contents)) >> +               memcpy(&insn, contents + rel->r_offset, sizeof(insn)); >> + >> +             if ((insn & 0xfc000000) == 0x4c000000) > This is tricky. But in commit 42bd525 we already started to rely on > undocumented %pc_{hi20,lo12} behavior: if you just apply them "as > documented" to the pcalau12i/jirl pairs the result will be absolutely > wrong. And 42bd525 behavior is not fully correct: if you just write > > pcalau12i $t0, %pc_hi20(data) > ld.d, $t0, $t0, %pc_lo12(data) Do you have a test case? > > With 42bd525, the BFD linker generates a "PLT for data" (absolutely > nonsense), and destroys the ld.d instruction. All of these buggy > behavior happens silently, the user will only find something wrong when > the linked program crashes. > > I'm not sure if checking JIRL (i. e. the behavior of a relocation now > depends on the instruction where it's applied) is a good idea. Maybe we > should use the following instead of pcalau12i/jirl: > > pcaddu18i $t0, %b16_hi20(func) > jirl $ra, $t0, %b16(func) > > ("b16_hi20" is a hypothetical thing here.) This will make things less > tricky, and also expand the range to 128 GiB. It doesn't make sense for only "pcaddu18i + jirl" to access 128G.What we need is a jump that can access ±2G, just like any other pc-relative instructions can access ±2G. --------------DE277EC6956739E63FBAB061--