Message ID | 20231215100633.65397-1-changjiachen@stu.xupt.edu.cn |
---|---|
Headers |
Return-Path: <binutils-bounces+ouuuleilei=gmail.com@sourceware.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:3b04:b0:fb:cd0c:d3e with SMTP id c4csp9163127dys; Fri, 15 Dec 2023 02:08:10 -0800 (PST) X-Google-Smtp-Source: AGHT+IF3aGWzo+CiAz6w2JF1wXgRHs935LV3xOxIXVDFqxaYg5PnzVwfNVbRYxN/zOSFxSpQVqwa X-Received: by 2002:a05:622a:54c:b0:41c:e129:87dc with SMTP id m12-20020a05622a054c00b0041ce12987dcmr16514315qtx.36.1702634889934; Fri, 15 Dec 2023 02:08:09 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1702634889; cv=pass; d=google.com; s=arc-20160816; b=T9goBlxasDb4K90m2PCl19GC6yJknWCIFupWjlVJSDTcNf9WzY/ldIg198JeP1fNAq iN4arJOHAgH563GfDohU8tE9Cr2iJCVdVDDYtvH3Ttlv/luGD+YNBHzDjidgJqBzS2Zl l6y3TZn0aT5JJyjQYsteAzDYd7dIAVC1Lwxcqy5d6j20GJzHmM9d21pttC15X7fA+UEm i1tJbSGJrR60VI88Ratcq787vjRVZj/keSj17CK6Z/aea9m0vj20lfaV7qeTDvHoXXqc XU5pLfaaF8fzYfU5uBJJGagZ4jgfJejDdIKhpYB5X5C805eV+n7OYHm50+MgBlN0aNAc vo8A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-transfer-encoding :mime-version:message-id:date:subject:cc:to:from:arc-filter :dmarc-filter:delivered-to; bh=ifRWqvxItwuz68PHAjpUpqrn0N/i3DKWZKLsu1U1hKk=; fh=uTF/VfpCAq2GtcL5NdCKul3VKQPlBSDYmUlZE/0CcYM=; b=x7zS9S2KMNiu/HzOio4FGhtV0pWRhyqE5ulkq9Z0/6xftjsYnxmzwYkTe0GEvIdXud fCPJxGEVgNSpdPA5+Z6JUvU+zBcM8ZIbECH4/ALHN4WR1rPpXo/po3lIIytcwx2VqiHh 7ZrH827DS3xw4hUhBrAlJA2Y5LWDHeCelpyq5meIF7lmFwDYV/LJCzyXoLCob7gASSOK ynJCRCGZa4BSiD0Cksy0X8/Mhy35fqFaxh8J2zFXw0qTAAkmjLDPFqtu9CkcGnwlWU6U L2aFFGZcETNhg/tNejW85ZmWKPgH3lk9anW7dFRBfx+UA6WE0MJNInt17gBD1dXo5joB Q0tQ== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xupt.edu.cn Received: from server2.sourceware.org (server2.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id bv25-20020a05622a0a1900b0042544ce91c9si18874436qtb.4.2023.12.15.02.08.09 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Dec 2023 02:08:09 -0800 (PST) Received-SPF: pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=xupt.edu.cn Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A8B4E3865490 for <ouuuleilei@gmail.com>; Fri, 15 Dec 2023 10:08:09 +0000 (GMT) X-Original-To: binutils@sourceware.org Delivered-To: binutils@sourceware.org Received: from mail-m155101.qiye.163.com (mail-m155101.qiye.163.com [101.71.155.101]) by sourceware.org (Postfix) with ESMTPS id 398513861869 for <binutils@sourceware.org>; Fri, 15 Dec 2023 10:06:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 398513861869 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=stu.xupt.edu.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=stu.xupt.edu.cn ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 398513861869 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=101.71.155.101 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702634810; cv=none; b=tEty/BJFQDPnTL3llcplsBs0AuoriOvHVb+DGAOf8zL7Wl1FHAFTGJKet4vsJzkw8pGd5iZASyaNK93JBK6gBu7oroJ4Y0yz5hRGWWPo8mjS0rsLD/0FTO+rL0Bfhm9XIGA8ipFMT8Lg3qAvSRku24Jw/6MVTJpAb+aQryCqkus= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702634810; c=relaxed/simple; bh=uhKchkwG0lJESDUrOh7n8O7jQvxlCCkX8MHTrPLlck8=; h=From:To:Subject:Date:Message-Id:MIME-Version; b=Gipe8BTV374Uie0+ni1cDH3jrBq4xIl3F9245UZ6QntE7eDSCjbBe3HHnla5Dq7ifngRx7uO/B/xsApJ+dV2ZNn4TG5NsCWT0+aT90l9x8nx8hAwLMIAVIbYDmVh4f5B8HwuC76r7SDQTTWYD7oLq96r/zk8bC7QknzIg1r9jhE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from ubuntu.localdomain (unknown [111.18.37.203]) by mail-m121144.qiye.163.com (Hmail) with ESMTPA id A2E76AC0071; Fri, 15 Dec 2023 18:06:34 +0800 (CST) From: changjiachen <changjiachen@stu.xupt.edu.cn> To: binutils@sourceware.org Cc: xuchenghua@loongson.cn, chenglulu@loongson.cn, liuzhensong@loongson.cn, xry111@xry111.site, 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, changjiachen <changjiachen@stu.xupt.edu.cn> Subject: [PATCH v3 0/5] LoongArch tls le model linker relaxation support. Date: Fri, 15 Dec 2023 18:06:28 +0800 Message-Id: <20231215100633.65397-1-changjiachen@stu.xupt.edu.cn> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFITzdXWS1ZQUlXWQ8JGhUIEh9ZQVkaQ0xPVkxMGExIGk4dGkNMSlUTARMWGhIXJBQOD1 lXWRgSC1lBWUpKSlVKQ1VITFVJS0hZV1kWGg8SFR0UWUFZT0tIVUpKS0hKQ1VKS0tVS1kG X-HM-Tid: 0a8c6cf1307fb039kuuua2e76ac0071 X-HM-MType: 10 X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Pwg6ODo6Ajw8Nzc5K1E#PVEO NDUaCytVSlVKTEtJTUhPTEJOQklNVTMWGhIXVRgTGhUcERIaGBMeFTsIDw5VAw4LD1UeHw5VGBVF WVdZEgtZQVlKSkpVSkNVSExVSUtIWVdZCAFZQU5IT043Bg++ X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, 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 X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Binutils mailing list <binutils.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/binutils>, <mailto:binutils-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/binutils/> List-Post: <mailto:binutils@sourceware.org> List-Help: <mailto:binutils-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/binutils>, <mailto:binutils-request@sourceware.org?subject=subscribe> Errors-To: binutils-bounces+ouuuleilei=gmail.com@sourceware.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785342082385236482 X-GMAIL-MSGID: 1785342082385236482 |
Series |
LoongArch tls le model linker relaxation support.
|
|
Message
changjiachen
Dec. 15, 2023, 10:06 a.m. UTC
This is the v3 version of patches to support loongarch linker tls le model relax. Changes from v2: * Some problems in the v2 patch are answered as follows. Question: use ".reloc.,R_LARCH_TLS_LE_ADD_R,sym" to generate relocation or %le_add_r(sym) to generate relocation. Reply: First, after a test, the R_LARCH_TLS_LE_ADD_R can be generated using ".reloc.,R_LARCH_TLS_LE_ADD_R,sym", or "%le_add_r(sym)". However,".reloc" generates R_LARCH_TLS_LE_ADD_R relocation directly, and it is not easy to add "R_LARCH_RELAX" relocation. "%le_add_r(sym)" Adds the R_LARCH_TLS_LE_ADD_R and R_LARCH_RELAX relocation commands, which is easier to implement. Of course, there is another way to generate ".reloc.,R_LARCH_TLS_LE_ADD_R,sym" and ".reloc.,R_LARCH_RELAX,sym" directly in gcc. However, this implementation causes the -mrelax/-mno-relax option to be set in both gcc and gas, which can be confusing. One problem with this is that add.d $r12,$r12,$r2 and add.d $r12,$r12,$r2, %le_add_r(sym) are too similar, so I have to add comments in loongarch_fix_opcodes[]. The goal is to make it as clear as possible to developers. * modified code format in loongarch_relax_tls_le(),use loongarch_relax_delete_bytes() instead of R_LARCH_DELETE to implement the delete instruction operation. * modified R_LARCH_TLS_LE_ADD_R type_name:"tls_le_add_r"-->"le_add_r". * modify comment information. * some comments added to "add.d" in loongarch_opcode loongarch_fix_opcodes[]. * remove some unnecessary content from the ld/testsuite/ld-loongarch test case. Changes from v1: * Modified v1-0000-cover-letter.patch part of the explanatory content. Before Modify: example: __thread int a = 1; old insn sequence: lu12i.w $r12,%le_hi20_r(a) ori $r12,$r12,%le_lo12_r(a) add.d $r12,$r12,$r2,%le_add_r(a) li.w $r13,$r0,1 stptr.w $r13,$r12,0 new insn sequence: lu12i.w $r12,%le_hi20_r(a) add.d $r12,$r12,$r2,%le_add_r(a) li.w $r13,$r0,1 st.w $r13,$r12,%le_lo12_r(a) After Modify: example: __thread int a = 1; old insn sequence(at the O0 optimization level): lu12i.w $r12,%le_hi20(a) ori $r12,$r12,%le_lo12(a) add.d $r12,$r12,$r2 addi.w $r13,$r0,1 stptr.w $r13,$r12,0 new insn sequence(at the O0 optimization level): lu12i.w $r12,%le_hi20_r(a) add.d $r12,$r12,$r2,%le_add_r(a) addi.w $r13,$r0,1 st.w $r13,$r12,%le_lo12_r(a) changjiachen (5): LoongArch: bfd: Add support for tls le relax. LoongArch: include: Add support for tls le relax. LoongArch: opcodes: Add support for tls le relax. LoongArch: gas: Add support for tls le relax. LoongArch: ld: Add support for tls le relax. bfd/bfd-in2.h | 4 + bfd/elfnn-loongarch.c | 76 +++++++++ bfd/elfxx-loongarch.c | 50 ++++++ bfd/libbfd.h | 3 + bfd/reloc.c | 6 + gas/config/tc-loongarch.c | 12 +- gas/testsuite/gas/loongarch/reloc.d | 18 +++ gas/testsuite/gas/loongarch/reloc.s | 11 ++ include/elf/loongarch.h | 12 ++ ld/testsuite/ld-loongarch-elf/old-tls-le.s | 19 +++ .../relax-bound-check-tls-le.s | 48 ++++++ ld/testsuite/ld-loongarch-elf/relax-tls-le.s | 17 ++ ld/testsuite/ld-loongarch-elf/relax.exp | 151 +++++++++++++++++- .../tls-relax-compatible-check-new.s | 29 ++++ .../tls-relax-compatible-check-old.s | 27 ++++ opcodes/loongarch-opc.c | 3 +- 16 files changed, 482 insertions(+), 4 deletions(-) create mode 100644 ld/testsuite/ld-loongarch-elf/old-tls-le.s create mode 100644 ld/testsuite/ld-loongarch-elf/relax-bound-check-tls-le.s create mode 100644 ld/testsuite/ld-loongarch-elf/relax-tls-le.s create mode 100644 ld/testsuite/ld-loongarch-elf/tls-relax-compatible-check-new.s create mode 100644 ld/testsuite/ld-loongarch-elf/tls-relax-compatible-check-old.s
Comments
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 ".reloc.,R_LARCH_TLS_LE_ADD_R,sym", > or "%le_add_r(sym)". However,".reloc" generates R_LARCH_TLS_LE_ADD_R relocation directly, and it is not > easy to add "R_LARCH_RELAX" relocation. "%le_add_r(sym)" Adds the R_LARCH_TLS_LE_ADD_R and R_LARCH_RELAX > relocation commands, which is easier to implement. > > Of course, there is another way to generate ".reloc.,R_LARCH_TLS_LE_ADD_R,sym" and > ".reloc.,R_LARCH_RELAX,sym" directly in gcc. However, this implementation causes the > -mrelax/-mno-relax option to be set in both gcc and gas, which can be confusing. 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, > %le_add_r(sym) are too similar, so I have to add comments in loongarch_fix_opcodes[]. > 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?
From: Xi Ruoyao <xry111@xry111.site> Date: 2023-12-15 20:34:50 To: changjiachen <changjiachen@stu.xupt.edu.cn>,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 Subject: Re: [PATCH v3 0/5] LoongArch tls le model linker relaxation support.>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 ".reloc.,R_LARCH_TLS_LE_ADD_R,sym", >> or "%le_add_r(sym)". However,".reloc" generates R_LARCH_TLS_LE_ADD_R relocation directly, and it is not >> easy to add "R_LARCH_RELAX" relocation. "%le_add_r(sym)" Adds the R_LARCH_TLS_LE_ADD_R and R_LARCH_RELAX >> relocation commands, which is easier to implement. >> >> Of course, there is another way to generate ".reloc.,R_LARCH_TLS_LE_ADD_R,sym" and >> ".reloc.,R_LARCH_RELAX,sym" directly in gcc. However, this implementation causes the >> -mrelax/-mno-relax option to be set in both gcc and gas, which can be confusing. > >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, >> %le_add_r(sym) are too similar, so I have to add comments in loongarch_fix_opcodes[]. >> 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? Hello, I understand what you mean. For the fourth operand of tls add.d instruction, I have made the following modifications. For the case of "add.d $a0,$a0,$a0,8", that is, when the fourth operand of the tls add.d instruction is not %le_add_r(sym), the modified assembler throws a "no match insn add.d $a0,$a0,$a0,8". example: a.s add.d $a0,$a0,$a0,8 $ gas/as-new a.s a.s: Assembler messages: a.s:1: error:no match insn: add.d $a0,$a0,$a0,8 Can such modification solve the problem you raised? I will add this change to v4 patch if possible. I am very much looking forward to your suggestions again. > >-- >Xi Ruoyao <xry111@xry111.site> >School of Aerospace Science and Technology, Xidian University
On Tue, 2023-12-19 at 13:33 +0800, 常佳琛 wrote: > For the case of "add.d $a0,$a0,$a0,8", that is, when the fourth operand of the tls add.d > instruction is not %le_add_r(sym), the modified assembler throws a "no match insn add.d $a0,$a0,$a0,8". > > example: > a.s > add.d $a0,$a0,$a0,8 > $ gas/as-new a.s > a.s: Assembler messages: a.s:1: error:no match insn: add.d $a0,$a0,$a0,8 Ok to me. Thanks.