From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id DAA83385800B; Tue, 12 Jul 2022 13:28:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DAA83385800B Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 25CFF22DAC; Tue, 12 Jul 2022 13:28:32 +0000 (UTC) Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id DCBA52C141; Tue, 12 Jul 2022 13:28:30 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id D4397663B; Tue, 12 Jul 2022 13:28:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id D207F6638; Tue, 12 Jul 2022 13:28:30 +0000 (UTC) Date: Tue, 12 Jul 2022 13:28:30 +0000 (UTC) From: Michael Matz To: Florian Weimer cc: Michael Matz via Libc-alpha , Adhemerval Zanella Netto , Alan Modra , caiyinyu , liuzhensong , WANG Xuerui , binutils@sourceware.org Subject: Re: glibc 2.36 - Slushy freeze (3 weeks to release) In-Reply-To: <87fsj6sc6p.fsf@oldenburg.str.redhat.com> Message-ID: References: <7aba5486-ac02-2088-221e-513a6892817a@linaro.org> <612c015a-8d77-d0ee-773a-c51e9cb1d239@linaro.org> <74d08933-d426-c25d-8496-5bd1c76c396b@linaro.org> <87fsj6sc6p.fsf@oldenburg.str.redhat.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 13:28:34 -0000 Hello, On Tue, 12 Jul 2022, Florian Weimer wrote: > > lenient in what you accept", even more so for something so basic as a > > program loader. It seems ill-advised to use ld.so to force something > > onto users that can only be called a strive for purity. > > The problem here is that R_*_NONE has historically been used in binutils > to indicate, “I did not recognize the relocation in the input file”, > while still generating an output file. The usual reason for _NONE are overallocated .rel output sections, where then further optimizations (after section sizes and hence base addresses are fixed) got rid of some of those relocations. (All these cases can be considered missed optimizations, but those happen easily) Unrecognizable input relocations are usually errored out on (and should be!) and don't lead to random _NONE output relocs, for exactly the reason you cited. Ciao, Michael.