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 6563838362CE for ; Thu, 1 Sep 2022 02:31:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6563838362CE 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 AQAAf8BxXWt7GRBj0WUOAA--.1816S3; Thu, 01 Sep 2022 10:31:23 +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> <3b43c733-6011-8c7c-4a1e-3faa9f91f711@loongson.cn> From: liuzhensong Message-ID: Date: Thu, 1 Sep 2022 10:31:23 +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: AQAAf8BxXWt7GRBj0WUOAA--.1816S3 X-Coremail-Antispam: 1UD129KBjvJXoWxAF18ur4DGr1ktFyUuFW3KFg_yoW5GFW5pr WxWw1qga1kXrn7uw18WF17X3W3Kan3Za1UJry5KwnFvrsxuFyxtryFvrsI9a1IkrWYyFW2 vrWUKrWj9as8AaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Yb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21lYx0E2Ix0 cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8Jw ACjcxG0xvEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCY 02Avz4vE-syl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1l4IxYO2xFxV AFwI0_Jrv_JF1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2 zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF 4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWU CwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCT nIWIevJa73UjIFyTuYvjxUqWxRDUUUU X-CM-SenderInfo: holx6xphqv003j6o00pqjv00gofq/ X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, 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 02:31:28 -0000 在 2022/9/1 上午10:12, Xi Ruoyao 写道: > On Thu, 2022-09-01 at 09:38 +0800, liuzhensong wrote: >>> 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? > $ cat t2.s > .text > .align 2 > .type x, @function > .global x > x: > pcalau12i $a0, %pc_hi20(data) > ld.d $a0, $a0, %pc_lo12(data) > jr $ra > $ gcc t2.s -c > $ ./ld/ld-new t2.o -shared > $ objdump -d | grep -A50 data > 0000000000000210 : > 210: 1c00010f pcaddu12i $t3, 8(0x8) > 214: 28f801ef ld.d $t3, $t3, -512(0xe00) > 218: 4c0001ed jirl $t1, $t3, 0 > 21c: 03400000 andi $zero, $zero, 0x0 > > Disassembly of section .text: > > 0000000000000220 : > 220: 1a000004 pcalau12i $a0, 0 > 224: 28c84084 ld.d $a0, $a0, 528(0x210) > 228: 4c000020 jirl $zero, $ra, 0 > > i.e. Instead of reporting an error like "cannot create a runtime > relocation against external symbol 'data'", the linker silently produces > a PLT (nonsense: can you use a PLT for data?) and load two instructions > from the PLT into the register (also nonsense). So if someone mistypes > "la.local" where "la.global" should be used (it's just a simple > programming mistake, and it's likely to happen in the practice!), the > linking will "succeeds" silently. Then the program blows up at runtime. This can be fixed as a bug. >> 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. > The point is, if we interpret %pc_lo12 "as it's documented": > > "(*(uint32_t *) PC) [21 ... 10] = (S+A) [11 ... 0]" > > it will be absolutely wrong for a jirl instruction. You may update the > doc to say something like "if R_LARCH_PCALA_LO12 is applied to a jirl > instruction, a PLT entry will be created and blah blah". But again I'm > not sure about if "the behavior of a relocation depends on the > instruction for which it's applied" is a good idea. > > We are using highly imprecise descriptions for PCALA-style > relocations in ELF psABI, despite I've disagreed in the review. Now if > someone wants to know "how this relocation will *really* behave", he/she > will need to read BFD code. PCALAU12I instruction itself is already > puzzling enough (comparing with PCADDU12I, which behaves more "normal"), > now the doc just makes it more puzzling. pcalau12i makes it easier to access 4k starting addresses, and pcaddu12i need more info in relocation. 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 6563838362CE for ; Thu, 1 Sep 2022 02:31:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6563838362CE 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 AQAAf8BxXWt7GRBj0WUOAA--.1816S3; Thu, 01 Sep 2022 10:31:23 +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> <3b43c733-6011-8c7c-4a1e-3faa9f91f711@loongson.cn> From: liuzhensong Message-ID: Date: Thu, 1 Sep 2022 10:31:23 +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="------------99A3372F8EE6409D289D279C" Content-Language: en-US X-CM-TRANSID:AQAAf8BxXWt7GRBj0WUOAA--.1816S3 X-Coremail-Antispam: 1UD129KBjvJXoWxAF18ur4DGr1ktFyUuFW3KFg_yoW5GFW5pr WxWw1qga1kXrn7uw18WF17X3W3Kan3Za1UJry5KwnFvrsxuFyxtryFvrsI9a1IkrWYyFW2 vrWUKrWj9as8AaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Yb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21lYx0E2Ix0 cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8Jw ACjcxG0xvEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCY 02Avz4vE-syl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1l4IxYO2xFxV AFwI0_Jrv_JF1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2 zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF 4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWU CwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCT nIWIevJa73UjIFyTuYvjxUqWxRDUUUU X-CM-SenderInfo: holx6xphqv003j6o00pqjv00gofq/ X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,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: <20220901023123.CEBzWOGA7utjSBmBIIOOEpA6qRjIIaXINaC4p4jeU_o@z> This is a multi-part message in MIME format. --------------99A3372F8EE6409D289D279C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 在 2022/9/1 上午10:12, Xi Ruoyao 写道: > On Thu, 2022-09-01 at 09:38 +0800, liuzhensong wrote: >>> 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? > $ cat t2.s > .text > .align 2 > .type x, @function > .global x > x: > pcalau12i $a0, %pc_hi20(data) > ld.d $a0, $a0, %pc_lo12(data) > jr $ra > $ gcc t2.s -c > $ ./ld/ld-new t2.o -shared > $ objdump -d | grep -A50 data > 0000000000000210 : > 210: 1c00010f pcaddu12i $t3, 8(0x8) > 214: 28f801ef ld.d $t3, $t3, -512(0xe00) > 218: 4c0001ed jirl $t1, $t3, 0 > 21c: 03400000 andi $zero, $zero, 0x0 > > Disassembly of section .text: > > 0000000000000220 : > 220: 1a000004 pcalau12i $a0, 0 > 224: 28c84084 ld.d $a0, $a0, 528(0x210) > 228: 4c000020 jirl $zero, $ra, 0 > > i.e. Instead of reporting an error like "cannot create a runtime > relocation against external symbol 'data'", the linker silently produces > a PLT (nonsense: can you use a PLT for data?) and load two instructions > from the PLT into the register (also nonsense). So if someone mistypes > "la.local" where "la.global" should be used (it's just a simple > programming mistake, and it's likely to happen in the practice!), the > linking will "succeeds" silently. Then the program blows up at runtime. This can be fixed as a bug. >> 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. > The point is, if we interpret %pc_lo12 "as it's documented": > > "(*(uint32_t *) PC) [21 ... 10] = (S+A) [11 ... 0]" > > it will be absolutely wrong for a jirl instruction. You may update the > doc to say something like "if R_LARCH_PCALA_LO12 is applied to a jirl > instruction, a PLT entry will be created and blah blah". But again I'm > not sure about if "the behavior of a relocation depends on the > instruction for which it's applied" is a good idea. > > We are using highly imprecise descriptions for PCALA-style > relocations in ELF psABI, despite I've disagreed in the review. Now if > someone wants to know "how this relocation will *really* behave", he/she > will need to read BFD code. PCALAU12I instruction itself is already > puzzling enough (comparing with PCADDU12I, which behaves more "normal"), > now the doc just makes it more puzzling. pcalau12i makes it easier to access 4k starting addresses, and pcaddu12i need more info in relocation. --------------99A3372F8EE6409D289D279C--