From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 484243858292 for ; Tue, 19 Jul 2022 03:58:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 484243858292 Received: by mail-pl1-x631.google.com with SMTP id f11so10839138plr.4 for ; Mon, 18 Jul 2022 20:58:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=voRC7HV+/GoC2Ppa1NORQjsw8rqMO5GC+s/6cKUi34o=; b=Q3A9bjdwWMpAXvUOr7CKv+CS5ROnTcNZE23bhrv4fJdw24BtT2/+al3bb/5D41/mHn XyQsQvlNEsmc18y9p4rHSuFaToAnoAO7lzt5QaCjiV17MwP3m1blnnn0+S2jaMV5cguT 3asP3ZB6JlwPe1d2VtGU6t8Z5L63Ad/fb2h9+N7sW+181UR2+Y8OabsvfpO3i4Kq03cK CoPYaYqqvJX/nQVRgrKsbLMOUaivbJcu76m6MMVNR3qikl16pxbB2D/OU/Qxi+YmLfsB P4PaZRNEoUP8IbwN0G91NKPmhLFv9acp2Vcz1XSC0qSiHWCGHIB3rtLcZ7jpkZybChfz ZGCg== X-Gm-Message-State: AJIora/YNzqfCs+RSTbM3c0AROJ9Jsh/r1jpEcnGM3nHixWNBWpnDMDF aj7ict3x45pjI04oBzXm2/OLKDkLIRWB/w== X-Google-Smtp-Source: AGRyM1u4X3fu4088JJjoDX9ZWntQgIdblC2nhz14QoE59mAlHM5fWqSehjMsUUQytxA0Q3zb0Q4MgA== X-Received: by 2002:a17:903:245:b0:16b:9b6d:20bc with SMTP id j5-20020a170903024500b0016b9b6d20bcmr30408585plh.14.1658203083132; Mon, 18 Jul 2022 20:58:03 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:9a19:c201:5910:e1d1]) by smtp.gmail.com with ESMTPSA id 199-20020a6218d0000000b0052abc2438f1sm10089116pfy.55.2022.07.18.20.58.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Jul 2022 20:58:02 -0700 (PDT) Date: Mon, 18 Jul 2022 20:57:58 -0700 From: Fangrui Song To: WANG Xuerui Cc: Xi Ruoyao , liuzhensong , binutils@sourceware.org, xuchenghua@loongson.cn, mengqinggang@loongson.cn Subject: Re: [PATCH 1/5 v1] LoongArch: bfd: Add new reloc types. Message-ID: <20220719035758.lshojc63snxcq6g2@google.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <417f93f5-64ca-9eb1-c338-b55edfd8eb83@xen0n.name> X-Spam-Status: No, score=-18.4 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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: Tue, 19 Jul 2022 03:58:06 -0000 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. >>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. >