From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [IPv6:2001:470:683e::1]) by sourceware.org (Postfix) with ESMTPS id B0073385828D; Tue, 12 Jul 2022 09:25:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B0073385828D Received: from [IPv6:240e:358:1190:c100:dc73:854d:832e:2] (unknown [IPv6:240e:358:1190:c100: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)) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id A0A7D66955; Tue, 12 Jul 2022 05:25:05 -0400 (EDT) Message-ID: Subject: Re: glibc 2.36 - Slushy freeze (3 weeks to release) From: Xi Ruoyao To: WANG Xuerui , Fangrui Song , Alan Modra Cc: Adhemerval Zanella Netto , Carlos O'Donell , libc-alpha , binutils@sourceware.org, caiyinyu , liuzhensong Date: Tue, 12 Jul 2022 17:24:58 +0800 In-Reply-To: References: <7aba5486-ac02-2088-221e-513a6892817a@linaro.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.3 MIME-Version: 1.0 X-Spam-Status: No, score=-1.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: 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: Tue, 12 Jul 2022 09:25:15 -0000 On Tue, 2022-07-12 at 14:42 +0800, WANG Xuerui wrote: > It's generally nice to be able to remove dubious/superfluous/unused=20 > code, but doing so must not negatively affect users. I'm personally in > support of removing such code, but as others have pointed out, it's=20 > unfortunate that the LoongArch port turns out to have "inherited" the=20 > wart from elsewhere, so the removal should not be done lightly (and=20 > break users' systems). I can live with either (1) Fix Binutils-2.39 ASAP and remove R_LARCH_NONE handling in Glibc.=20 And document "To build Glibc-2.36 or any code link to Glibc-2.36 for LoongArch, Binutils >=3D 2.39 is needed." (2) Work around R_LARCH_NONE in Glibc rtld code. The advantage of (1) is we can get rid of "some stupid code" and make some marginal performance gain. The disadvantage is we are too close to the deadline (glibc-2.36 and binutils-2.39 due date) and if we fail we'll wait for another 6 months to upstream Glibc. But, "just remove R_LARCH_NONE in Glibc rtld and tell everyone to build Glibc-2.36 (and everything link to it) for LoongArch with /path/to/not/reviewed/binutils.git/some-fancy-branch" is not acceptable to me. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University