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 A7EF8385828A for ; Wed, 20 Jul 2022 07:47:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A7EF8385828A 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.151] (unknown [10.20.4.151]) by mail.loongson.cn (Coremail) with SMTP id AQAAf9Dxr9AWs9diZS0qAA--.38048S3; Wed, 20 Jul 2022 15:47:34 +0800 (CST) Subject: Re: [PATCH 1/5 v1] LoongArch: bfd: Add new reloc types. To: Fangrui Song , WANG Xuerui Cc: Xi Ruoyao , binutils@sourceware.org, xuchenghua@loongson.cn, mengqinggang@loongson.cn References: <20220718084316.390672-1-liuzhensong@loongson.cn> <8b637076-eb4c-47e0-2987-ac0973e38bca@xen0n.name> <62de74c5cfc7e558f82025ccffe5547d58bff172.camel@xry111.site> <417f93f5-64ca-9eb1-c338-b55edfd8eb83@xen0n.name> <20220719035758.lshojc63snxcq6g2@google.com> From: liuzhensong Message-ID: <0fbc1017-269d-aa8c-7b1c-7bdd8abb3308@loongson.cn> Date: Wed, 20 Jul 2022 15:47:33 +0800 User-Agent: Mozilla/5.0 (X11; Linux loongarch64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20220719035758.lshojc63snxcq6g2@google.com> Content-Language: en-US X-CM-TRANSID: AQAAf9Dxr9AWs9diZS0qAA--.38048S3 X-Coremail-Antispam: 1UD129KBjvJXoW3XFyUCFW5tw4kZw43XFWkJFb_yoW7KF1fpr 4vyw1xGrWDXF1xCw18ZrWUG34xXr1xCw4UJF1UKa95AF1kA34FqrsrX3s0gr17CrWkJr1r XF1UJF1Svr1jqrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvI14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26ryj6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4j 6r4UJwA2z4x0Y4vEx4A2jsIE14v26F4UJVW0owA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gc CE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2 z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4x0x7Aq67 IIx4CEVc8vx2IErcIFxwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG 8wCY02Avz4vE-syl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxV Aqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r12 6r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE 14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf 9x0JUtkuxUUUUU= X-CM-SenderInfo: holx6xphqv003j6o00pqjv00gofq/ X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, BODY_8BITS, HTML_MESSAGE, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP 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: Wed, 20 Jul 2022 07:47:41 -0000 在 2022/7/19 上午11:57, Fangrui Song 写道: > On 2022-07-18, WANG Xuerui wrote: >> On 2022/7/18 19:33, Xi Ruoyao wrote: >>> On Mon, 2022-07-18 at 18:06 +0800, WANG Xuerui wrote: >>>> (Adding Ruoyao and MaskRay to CC, who might be interested in this >>>> development as well, as it concerns the linker implementation.) >>> I've already subscribed binutils@sourceware.org in order not to be >>> passed by. > > I am subscribed, too. Direct CC helps me find the discussions:) > >>>> I think I've voiced my concerns over the naming of these ops multiple >>>> times already; the primary comment ([1]; in English) was posted >>>> back in >>>> May but no one in your team responded. >>>> >>>> Reproducing the content (and adjusting a little) here: >>>> >>>> >>>> Overall in a good direction (and IMHO the direction everyone should >>>> have >>>> taken in the first place), thanks! >>>> >>> Yes, we've been paying additional costs using those "stack based >>> relocation".  I'd like to know why they were proposed in first place? >>> (Not accusing anyone, just my curiosity: AFAIK no other targets ever >>> used such a stack for relocation.) >> As previously pointed out on this list, rx and rl78 both use >> stack-based relocs. (Both come from Renesas, so I do think it's >> delibrate design decision, but of course the original Renesas >> justification is most probably buried in history.) I explained this >> in https://github.com/loongson/binutils-gdb/issues/134 before. > > Stack machines aren't really suitable for ELF relocations. > Each relocation takes sizeof(Elf64_Rela) = 24 byte, higher than older > object file formats. > > ELF32 allows 256 relocation types. There aren't too many to waste. > >>> >>> /* snip */ >>> >>> >>>> FYI, I did make a list of my suggested names for these reloc types >>>> ("BFD_RELOC_LARCH_" abbreviated to "B_R_L_"): >>>> >>>> Original name           Suggested name >>>> -------------           -------------- >>>> B_R_L_B16               B_R_L_PCREL_SK16 *1 >>>> B_R_L_B21               B_R_L_PCREL_SD5K16 >>>> B_R_L_B26               B_R_L_PCREL_SD10K16 >>>> B_R_L_ABS_LO12          B_R_L_ABS_0_SK12 >>>> B_R_L_ABS_HI20          B_R_L_ABS_12_SJ20 >>>> B_R_L_ABS64_LO20        B_R_L_ABS_32_SJ20 >>>> B_R_L_ABS64_HI12        B_R_L_ABS_52_SK12 > > aarch64 calls these G0/G1/G2/G3 while ppc calls these > LO/HI/HIGHER/HIGHEST. > A name mentioning the offset and the length looks good to me, too. > A too-long name may have problems in the default (non-wide) output of > readelf -r. > >>>> B_R_L_PCALA_LO12 B_R_L_PCALA_0_SK12 *2 >>>> B_R_L_PCALA_HI20        B_R_L_PCALA_12_SJ20 >>>> B_R_L_PCALA64_LO20      B_R_L_PCALA_32_SJ20 *3 >>>> B_R_L_PCALA64_HI12      B_R_L_PCALA_52_SK12 >>>> B_R_L_GOT_PC_LO12       B_R_L_GOT_PCALA_0_SK12 *4 >>>> B_R_L_GOT_PC_HI20       B_R_L_GOT_PCALA_12_SJ20 >>>> B_R_L_GOT64_PC_LO20     B_R_L_GOT_PCALA_32_SJ20 >>>> B_R_L_GOT64_PC_HI12     B_R_L_GOT_PCALA_52_SK12 >>>> B_R_L_GOT64_LO12        B_R_L_GOT_ABS_0_SK12 *5 >>>> B_R_L_GOT64_HI20        B_R_L_GOT_ABS_12_SJ20 >>>> B_R_L_GOT64_LO20        B_R_L_GOT_ABS_32_SJ20 >>>> B_R_L_GOT64_HI12        B_R_L_GOT_ABS_52_SK12 > > >>>> B_R_L_TLS_LE_LO12 B_R_L_TLS_LE_ABS_0_SK12 >>>> B_R_L_TLS_LE_HI20       B_R_L_TLS_LE_ABS_12_SJ20 >>>> B_R_L_TLS_LE64_LO20     B_R_L_TLS_LE_ABS_32_SJ20 >>>> B_R_L_TLS_LE64_HI12     B_R_L_TLS_LE_ABS_52_SK12 >>>> B_R_L_TLS_IE_PC_LO12    B_R_L_TLS_IE_PCALA_0_SK12 >>>> B_R_L_TLS_IE_PC_HI20    B_R_L_TLS_IE_PCALA_12_SJ20 >>>> B_R_L_TLS_IE64_PC_LO20  B_R_L_TLS_IE_PCALA_32_SJ20 >>>> B_R_L_TLS_IE64_PC_HI12  B_R_L_TLS_IE_PCALA_52_SK12 >>>> B_R_L_TLS_IE64_LO12     B_R_L_TLS_IE_ABS_0_SK12 >>>> B_R_L_TLS_IE64_HI20     B_R_L_TLS_IE_ABS_12_SJ20 >>>> B_R_L_TLS_IE64_LO20     B_R_L_TLS_IE_ABS_32_SJ20 >>>> B_R_L_TLS_IE64_HI12     B_R_L_TLS_IE_ABS_52_SK12 >>>> B_R_L_TLS_LD_PC_HI20    B_R_L_TLS_LD_PCALA_12_SJ20 *6 >>>> B_R_L_TLS_LD64_HI20     B_R_L_TLS_LD_ABS_12_SJ20 >>>> B_R_L_TLS_GD_PC_HI20    B_R_L_TLS_GD_PCALA_12_SJ20 >>>> B_R_L_TLS_GD64_HI20     B_R_L_TLS_GD_ABS_12_SJ20 > > aarch64 relocation types are well named. It's obvious what suppress > overflow checking. > > For LO12, I expect that there are two variants: one with overflow check, > the other without. > In what scenarios will no check overflow be used? Any documentation or examples? >>> It's overall better, but those "J, K" etc are cryptic IMHO.  And for >>> "B_R_L_B16" I think "B_R_L_PCREL_SK16" fails to express that the offset >>> should be shifted right by 2, so I'd keep B_R_L_B16 (and similarly, >>> B_R_L_B21 and B_R_L_B26) like the PCALA case. >>> >> The slot names come from >> https://github.com/loongson/LoongArch-Documentation/pull/56 (to >> non-Chinese speakers: English translation still TODO, but hopefully >> at least the ABNF and the few tables should be intelligible even >> without translation). >> >> As for the PCREL and implicit shifts, maybe a planned extension of >> the slot syntax could help. I plan to submit an Assembly Language >> Convention after the Instruction Format Convention gets reviewed and >> merged, and with this new convention such an extension is necessary >> anyway for accommodating the current assembly syntax as described by >> the ISA manual, able to express the <<2's and +1's for the >> PC-manipulating and ALSL insns. >> >> For example, let's say the extension works like this: ordinary slot >> syntax, plus "p", plus an postprocess operator, with "s\d+" for "imm >> slot = assembly operand >> N", and "p\d+" for "imm slot = assembly >> operand + N". Then we could say "B_R_L_PCREL_SK16PS2" and have all >> the niceties. (In an ideal world, the LoongArch opcodes >> implementation should be modified to use this convention too, so for >> example it will be something like "DJSk16ps2" for JIRL, "JDSk16ps2" >> for BLT (notice the reversed operand order) and "DJKUa2pp1" for ALSL >> insns. >>