From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id C974038582BD for ; Fri, 15 Dec 2023 12:34:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C974038582BD Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C974038582BD Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=89.208.246.23 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702643697; cv=none; b=Q5+3p6YxRqhZR0ppOTspxsSZht3umWaalTuPiTVLgi24J+kWGk2MH0XUVkV7/4a7iYk76DJUmyH3dgDCZnxYs364QHSYKoktUbp+2w3GiYqyXoboliqkxZr+YaKcWsKrpKfutj29kPQtcbwcQcI9OEInV/Bd6YD4HWXwDCh9qwc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702643697; c=relaxed/simple; bh=5juOHjqFmlw/VpaogCqccvBTTZlEnIsD79DSzhBi7Pw=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=u/Df77IPOHFtwHg0C+/UxJbOi888uJ23RkxROviWzAXOcuuD5I5FwFoZsRDOdZGikGcH9N5CissUg0TK7ORoDL18YhMGfG9cU+N4+mKc6+sVd2BV3MY8cJd6OWvE/v4JJErVN/pfO2S/9Vex2kRsrLfaHQV9dxnBGv/anpVdQZE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1702643695; bh=5juOHjqFmlw/VpaogCqccvBTTZlEnIsD79DSzhBi7Pw=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=VNnOnqMZVvkacxWqiJ40We9shiUZZ7hba/apHbl5f6ltE6PISNJZtEYLcWCNwYT0M r9ATRZ9/Mi6u20RNgrPipiLk/jRqWOY0h6UwnR0Df2GvIG8Tm9mueZxJtRD2Ty5woS OYHPZ3JOjAKLKZbxiLi8yR5Vy/FVfnBDfL0VRbuQ= Received: from [127.0.0.1] (unknown [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id BFEBC67065; Fri, 15 Dec 2023 07:34:52 -0500 (EST) Message-ID: <89b2e2062115e127965a4bd6b64e9181d397b7bf.camel@xry111.site> Subject: Re: [PATCH v3 0/5] LoongArch tls le model linker relaxation support. From: Xi Ruoyao To: changjiachen , binutils@sourceware.org Cc: xuchenghua@loongson.cn, chenglulu@loongson.cn, liuzhensong@loongson.cn, i.swmail@xen0n.name, maskray@google.com, cailulu@loongson.cn, luweining@loongson.cn, wanglei@loongson.cn, hejinyang@loongson.cn, Lazy_Linux@126.com, mengqinggang@loongson.cn Date: Fri, 15 Dec 2023 20:34:50 +0800 In-Reply-To: <20231215100633.65397-1-changjiachen@stu.xupt.edu.cn> References: <20231215100633.65397-1-changjiachen@stu.xupt.edu.cn> Autocrypt: addr=xry111@xry111.site; prefer-encrypt=mutual; keydata=mDMEYnkdPhYJKwYBBAHaRw8BAQdAsY+HvJs3EVKpwIu2gN89cQT/pnrbQtlvd6Yfq7egugi0HlhpIFJ1b3lhbyA8eHJ5MTExQHhyeTExMS5zaXRlPoiTBBMWCgA7FiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQrKrSDhnnEOPHFgD8D9vUToTd1MF5bng9uPJq5y3DfpcxDp+LD3joA3U2TmwA/jZtN9xLH7CGDHeClKZK/ZYELotWfJsqRcthOIGjsdAPuDgEYnkdPhIKKwYBBAGXVQEFAQEHQG+HnNiPZseiBkzYBHwq/nN638o0NPwgYwH70wlKMZhRAwEIB4h4BBgWCgAgFiEEkdD1djAfkk197dzorKrSDhnnEOMFAmJ5HT4CGwwACgkQrKrSDhnnEOPjXgD/euD64cxwqDIqckUaisT3VCst11RcnO5iRHm6meNIwj0BALLmWplyi7beKrOlqKfuZtCLbiAPywGfCNg8LOTt4iMD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.2 MIME-Version: 1.0 X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, 2023-12-15 at 18:06 +0800, changjiachen wrote: > First, after a test, the R_LARCH_TLS_LE_ADD_R can be generated using ".re= loc.,R_LARCH_TLS_LE_ADD_R,sym",=20 > or "%le_add_r(sym)". However,".reloc" generates R_LARCH_TLS_LE_ADD_R relo= cation directly, and it is not=20 > easy to add "R_LARCH_RELAX" relocation. "%le_add_r(sym)" Adds the R_LARCH= _TLS_LE_ADD_R and R_LARCH_RELAX=20 > relocation commands, which is easier to implement. > > Of course, there is another way to generate ".reloc.,R_LARCH_TLS_LE_ADD_R= ,sym" and=20 > ".reloc.,R_LARCH_RELAX,sym" directly in gcc. However, this implementation= causes the=20 > -mrelax/-mno-relax option to be set in both gcc and gas, which can be con= fusing. GCC 14 already have -mrelax/-mno-relax options. This is not confusing at all. > One problem with this is that add.d $r12,$r12,$r2 and add.d $r12,$r12,$r2= ,=20 > %le_add_r(sym) are too similar, so I have to add comments in loongarch_fi= x_opcodes[].=20 > The goal is to make it as clear as possible to developers. No, normal developers (not Binutils developers) should not be mandated to read Binutils code to understand something. OTOH they should read the documentation of GAS. So make it clear somewhere in the doc. And I've told you if you must go with an additional operand in add.d, you should reject things like: add.d $a0,$a0,$a0,8 but now: $ cat t.s add.d $a0,$a0,$a0,8 $ gas/as-new t.s $ binutils/objdump -d a.out a.out: file format elf64-loongarch Disassembly of section .text: 0000000000000000 <.text>: 0: 0010b084 add.d $a0, $a0, $t0 Now is it clear that this behavior is unacceptable? Is it too difficult or unreasonable to make it an error with message "the fourth operand of the add.d instruction must be %le_add_r"?! Or didn't I make it clear? --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University