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 443A0381158C for ; Sun, 30 Jun 2024 02:55:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 443A0381158C 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 443A0381158C 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=1719716152; cv=none; b=H8vjc+hpLFlcFiphziWDya1j0jNJypl27LyCxJhPn6y4q9JTz4xdQVWkESO3aBDpKqUeRQBK1TOR7LI5fSMIAMuYDE+sEnelhqb7NR+MSx8uNrO6ZE6rHV0kKN9XfL9f40hqJnc4aptWPIfx0p7ZIMbP1pBnR83ycQ0FUhHJSmM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719716152; c=relaxed/simple; bh=UrrWDXbef0ResMMv3YkYcWeVqlapUdEjkV1jwl1/uDs=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=jhu3nAi+AvJh8NzW56tx0IoKy5vAGenUK1npMjUXaxTSMMKBld3ofiB3P8Y0NSJNF6sfgm8J0NK8eOwx7kl0QFsE/yYWTAzTwqzaHr5LUcvJMHhqm7PvPiBS+CTnJCSZry4pWjwkYbwE0uC3QbC6EthJhblq2l114S2jQ5GL6yk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1719716147; bh=UrrWDXbef0ResMMv3YkYcWeVqlapUdEjkV1jwl1/uDs=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=DzdSuv3AFuZPpAXkiaLLoT5kaAyl/7JbXjtsJ9Wrv3hbM4V8XAO8nScIxApgqWbuB f/RCi+ccbZ32/gru+SJjSPjm+AAx9v1N4Ay3UxTnEuSTWu7yymCcewfq4EdlWfCix8 pYeVYryMWMFffn1XhAaXz9Ps+fTWOIZoCJhBq9N0= Received: from [IPv6:240e:358:118a:c500:dc73:854d:832e:2] (unknown [IPv6:240e:358:118a:c500:dc73:854d:832e:2]) (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 8D75566EA4; Sat, 29 Jun 2024 22:55:44 -0400 (EDT) Message-ID: <4b4d3a90a43cf704c3328910fe236dbd50918dd8.camel@xry111.site> Subject: Re: [PATCH v2 1/5] LoongArch: Reject R_LARCH_32 from becoming a runtime reloc in ELFCLASS64 From: Xi Ruoyao To: Jinyang He , Fangrui Song Cc: binutils@sourceware.org, mengqinggang@loongson.cn, Zhensong Liu , i.swmail@xen0n.name, maskray@google.com, Szabolcs Nagy Date: Sun, 30 Jun 2024 10:55:40 +0800 In-Reply-To: <9e2e6b1e-b893-aaa2-2646-17d5190d045c@loongson.cn> References: <20240626100453.98946-2-xry111@xry111.site> <20240626100453.98946-3-xry111@xry111.site> <393a77d407023cfced90c8a6f6d1946112eeaf0a.camel@xry111.site> <15542d6a-ad36-b9c2-ee1b-c72bbb881f4f@loongson.cn> <9e2e6b1e-b893-aaa2-2646-17d5190d045c@loongson.cn> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.2 MIME-Version: 1.0 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP 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 Sat, 2024-06-29 at 21:56 +0800, Jinyang He wrote: > =E5=9C=A8 2024/6/29 1:04, Fangrui Song =E5=86=99=E9=81=93: >=20 > > On Thu, Jun 27, 2024 at 6:53=E2=80=AFPM Jinyang He wrote: > > > On 2024-06-28 01:19, Xi Ruoyao wrote: > > >=20 > > > > On Thu, 2024-06-27 at 20:39 +0800, Xi Ruoyao wrote: > > > > > > I'd like to do this rejection earlier in `check_relocs` than > > > > > > `relocate_section`. Generally loongarch32 do not produce R_LARC= H_64, > > > > > > so this rejection should be efficient only for R_LARCH_32 on > > > > > > loongarch64. > > > > > Ok, in V3 I'll use the same approach as RISC-V then. > > > > And after some thinking: R_LARCH_64 on loongarch32 should be fine.= =C2=A0 On > > > > little-endian hardware *(uint64 *)pc +=3D load_addr should be same = as > > > > *(uint32 *)pc +=3D load_addr unless the latter wraps, but if it wra= ps > > > > Glibc dynamic linker should complain anyway. > > > >=20 > > > > RISC-V also converts R_RISCV_64 to R_RISCV_RELATIVE for rv32. > > > Yes, you're right. I think we cannot avoid asm like `.8byte .L1` or > > > `.8byte .L1 - .L2`, so emiting 64bits static reloc type on loongarch3= 2 > > > makes sense. > > >=20 > > x86-32, aarch32, ppc32, and s390 ports do not support `.quad .L1`. > > mips32 and riscv32 accept `.quad .L1`, which might be a mistake. > >=20 > > Why cannot '.8byte .L1` be avoided? > Thank you for providing the detailed list. To be frankly, I sometimes see > how RISCV does and think how LoongArch should do. I'm sorry for lack > of in-depth thinking. >=20 > I think users may handwrite asm codes for 32-bits and 64 bits machines. For supporting this IMO we should add more functionalities like ld.p/st.p/ldptr.p/stptr.p/addi.p/add.p/sub.p which is assembled to ld.d etc. for lp64, and ld.w etc. for ilp32. Now every project is defining a bunch of macros for these, and IMO it's better to just support them in GAS so new projects won't need to define their own macros anymore. And similarly, for hard coding a pointer to x we can also add a directive like ".ptr x", which behaves like ".4byte x" for ilp32 and ".8byte x" for lp64. I'm modifying my code to "do things RISC-V is doing" for now. When we finalize ilp32 support we can revise. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University