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 457A43858C83 for ; Fri, 19 Aug 2022 13:46:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 457A43858C83 Received: from [IPv6:240e:358:11e4:a00:dc73:854d:832e:4] (unknown [IPv6:240e:358:11e4:a00:dc73:854d:832e:4]) (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 BD5BB6683A; Fri, 19 Aug 2022 09:46:45 -0400 (EDT) Message-ID: Subject: Re: [PATCH 1/1] LoongArch: Add pointer mangling support. From: Xi Ruoyao To: Joseph Myers Cc: xuchenghua@loongson.cn, i.swmail@xen0n.name, libc-alpha@sourceware.org, caiyinyu Date: Fri, 19 Aug 2022 21:46:37 +0800 In-Reply-To: References: <20220811040056.3164122-1-caiyinyu@loongson.cn> <3740676145dbfab3595458d7a730272acd6fb928.camel@xry111.site> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.45.2 MIME-Version: 1.0 X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FROM_SUSPICIOUS_NTLD, LIKELY_SPAM_FROM, PDS_OTHER_BAD_TLD, 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 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2022 13:46:51 -0000 On Wed, 2022-08-17 at 16:46 +0000, Joseph Myers wrote: > On Wed, 17 Aug 2022, Xi Ruoyao via Libc-alpha wrote: >=20 > > I share your feeling...=C2=A0 But the fix needed by ld.so (bc2a35c in > > binutils-gdb.git) is after two commits massively changing the relocatio= n > > types.=C2=A0 Backporting the relocation type changes is completely > > unacceptable (such an attempt will do nothing except annoying Nick > > Clifton :). And bc2a35c alone cannot be backported trivially. >=20 > If the branch isn't usable as-is on LoongArch (which apparently is the > state at present), there should be no problem with any backport to=20 > architecture-specific code, regardless of how large it is - it can't=20 > exactly regress from "not usable". Sorry, my memory was flawed when I wrote the last reply (due to my 2- week vacation :( ). It's not completely usable, only IFUNC is broken. > I note that the only GCC target supported for LoongArch is=20 > loongarch*-*-linux*, so there isn't really a question of being usable for= =20 > bare-metal either. >=20 --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University