From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from arjuna.pair.com (arjuna.pair.com [209.68.5.131]) by sourceware.org (Postfix) with ESMTPS id 68C033858D32; Fri, 15 Jul 2022 22:34:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 68C033858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bitrange.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bitrange.com Received: by arjuna.pair.com (Postfix, from userid 3006) id 3C0FC8A59C; Fri, 15 Jul 2022 18:34:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by arjuna.pair.com (Postfix) with ESMTP id 3864C8A591; Fri, 15 Jul 2022 18:34:52 -0400 (EDT) Date: Fri, 15 Jul 2022 18:34:52 -0400 (EDT) From: Hans-Peter Nilsson X-X-Sender: hp@arjuna.pair.com To: Michael Matz cc: Florian Weimer , Michael Matz via Libc-alpha , caiyinyu , liuzhensong , binutils@sourceware.org Subject: Re: glibc 2.36 - Slushy freeze (3 weeks to release) In-Reply-To: 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.16 (BSF 172 2016-09-29) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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: 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, 15 Jul 2022 22:34:54 -0000 On Tue, 12 Jul 2022, Michael Matz via Binutils wrote: > 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. (From the department of opinions nobody asked for:) This is IMHO the most correct assessment. And, beware of adding new potentially relocation-removing linker optimizations after section layout. I'd add something about fighting windmills, but the "strive for purity" fits nicely. :) brgds, H-P