From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailbox.box.xen0n.name (mail.xen0n.name [115.28.160.31]) by sourceware.org (Postfix) with ESMTPS id 317BE3852742 for ; Mon, 18 Jul 2022 12:11:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 317BE3852742 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=xen0n.name Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xen0n.name DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xen0n.name; s=mail; t=1658146288; bh=+3o7IneMDkeFX/ISlXItnmVArtDy4e8R9QjZsnp4y8M=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=EyTPNY2kVg3k8Xff9jMdmZqE8G6fVVRfl6Zix05l/i4GVz95mM8tH926u0hkd++9S P8hHSqfyW2EVLRRCaANZSoq1T4UguNiiuGqUPrD+rDFuLFsb8qsR4MUGKpog6MSvSQ 1ivG3Vt4OzSNeeGYB8m6dx2AdfT5lXxPL4a3hxAM= Received: from [100.100.57.190] (unknown [220.248.53.61]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailbox.box.xen0n.name (Postfix) with ESMTPSA id 15F5260104; Mon, 18 Jul 2022 20:11:28 +0800 (CST) Message-ID: <417f93f5-64ca-9eb1-c338-b55edfd8eb83@xen0n.name> Date: Mon, 18 Jul 2022 20:11:27 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:104.0) Gecko/20100101 Thunderbird/104.0a1 Subject: Re: [PATCH 1/5 v1] LoongArch: bfd: Add new reloc types. Content-Language: en-US To: Xi Ruoyao , WANG Xuerui , liuzhensong , binutils@sourceware.org Cc: xuchenghua@loongson.cn, mengqinggang@loongson.cn, Fangrui Song References: <20220718084316.390672-1-liuzhensong@loongson.cn> <8b637076-eb4c-47e0-2987-ac0973e38bca@xen0n.name> <62de74c5cfc7e558f82025ccffe5547d58bff172.camel@xry111.site> From: WANG Xuerui In-Reply-To: <62de74c5cfc7e558f82025ccffe5547d58bff172.camel@xry111.site> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_NONE, 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 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: Mon, 18 Jul 2022 12:11:35 -0000 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 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. > > /* 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 >> 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 > 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.