From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailbox.box.xen0n.name (mail.xen0n.name [115.28.160.31]) by sourceware.org (Postfix) with ESMTPS id BEFFF385828D; Tue, 12 Jul 2022 06:42:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BEFFF385828D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=xen0n.name Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xen0n.name DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xen0n.name; s=mail; t=1657608143; bh=zCLVy4XA4MqKrjlDKL5Gr5fT4YwGNL/ZwD1v0X0vWLU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=dlgyU2q6LTQ3LnZENdfGHnrVK+teelbpX1sO1N/DU4j+wIZrrTHCno1nPbk1TuRAu 79FXG+gdEeQAMBZC0RHkIb0YNxJE+4Xdf7eS08AJ9P14bNa8PMzYkFQpo97ZMULCo6 oKsN9NlsTDGuGHNQThbiprs37N0finh0Qx8yqbUs= Received: from [100.100.57.190] (unknown [220.248.53.61]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailbox.box.xen0n.name (Postfix) with ESMTPSA id 6ADFD60091; Tue, 12 Jul 2022 14:42:23 +0800 (CST) Message-ID: Date: Tue, 12 Jul 2022 14:42:23 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:104.0) Gecko/20100101 Thunderbird/104.0a1 Subject: Re: glibc 2.36 - Slushy freeze (3 weeks to release) To: Fangrui Song , Alan Modra Cc: Xi Ruoyao , Adhemerval Zanella Netto , Carlos O'Donell , libc-alpha , binutils@sourceware.org, caiyinyu , liuzhensong References: <7aba5486-ac02-2088-221e-513a6892817a@linaro.org> Content-Language: en-US From: WANG Xuerui In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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.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 06:42:34 -0000 On 2022/7/12 12:24, Fangrui Song wrote: > On Mon, Jul 11, 2022 at 7:32 PM Alan Modra wrote: >> On Tue, Jul 12, 2022 at 08:48:18AM +0800, Xi Ruoyao via Binutils wrote: >>>> The R_LARCH_NONE issue should only affect performance, >>>> since it should be ignored by loader although I am not sure without >>>> understanding better the issue. >> R_*_NONE relocs are harmless in an executable or shared library, if >> their presence is due to overallocating space for relocations. Of >> course, if ld should actually be emitting some other dynamic reloc >> type then that is a more serious problem. >> >>> Fangrui suggested [2] we should assume R_LARCH_NONE does not exist to >>> simplify the code and catch ld bugs earlier. >> Yes that will annoy your user base into reporting bugs. How much do >> you want to annoy them? You might like to consider why other major >> architectures with mature linkers process and ignore R_*_NONE relocs >> in the loader.. > If a linker port has a high confidence level, removing dynamic > R_*_NONE support from the loader shall be the right thing. > I can understand that there may not be the case in GNU ld as I've seen > such bugs in riscv (e.g. > https://sourceware.org/bugzilla/show_bug.cgi?id=24673), too (I think > gold, lld, and mold make it difficult to make such bugs). > But I did wish that a fresh port of a new arch in binutils had fixed > all such bugs. I realized it might be the case for LoongArch, so > keeping R_LARCH_NONE support in glibc ld.so may be fine. It's generally nice to be able to remove dubious/superfluous/unused 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 unfortunate that the LoongArch port turns out to have "inherited" the wart from elsewhere, so the removal should not be done lightly (and break users' systems). All is not lost, though, as the LoongArch "new world" (the fully community-driven openly developed ABI we're currently all working on, as opposed to the stopgap MIPS-esque ABI Loongson initially shipped in commercial products) is nowhere near popular, at least in the 1~1.5 years to come; and we as distribution packages already educate the current "seed" users of new-world LoongArch to expect to update or re-install as often as possible to stay on the bleeding edge. So IMO fixing the linker and sunsetting R_LARCH_NONE support in glibc loader could be feasible after all, just it won't be a quick process.