From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id BFB1F3858C39; Fri, 29 Oct 2021 12:47:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BFB1F3858C39 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 0452E1FD61; Fri, 29 Oct 2021 12:47:26 +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 F07DFA3B81; Fri, 29 Oct 2021 12:47:25 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id E8B1B6687; Fri, 29 Oct 2021 12:47:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id E684462B2; Fri, 29 Oct 2021 12:47:25 +0000 (UTC) Date: Fri, 29 Oct 2021 12:47:25 +0000 (UTC) From: Michael Matz To: "H.J. Lu" cc: Florian Weimer , "H.J. Lu via Libc-alpha" , Binutils Subject: Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED In-Reply-To: Message-ID: References: <87zgqvq03g.fsf@oldenburg.str.redhat.com> <87v91hljth.fsf@oldenburg.str.redhat.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 29 Oct 2021 12:47:28 -0000 Hello, On Thu, 28 Oct 2021, H.J. Lu via Binutils wrote: > > >> This proposal may conflict in spirit with the glibc proposal to support > > >> preloadable symbol version (so you can add _dl_find_eh_frame@GLIBC_2.35 > > >> to a glibc 2.28 installation, for example). So far, symbol versions > > > > > > Why will adding a glibc version dependency change the preload > > > behavior? > > > > Previously, we thought we could relax the version coverage check to > > enable adding completely new symbol versions by preloading an > > implementation. With BIND_NOW, this is completely safe because missing > > symbols are still detected. But this turns unreliable once glibc > > versions are tied to ELF implementation features. Preloading an > > implementation of _dl_find_eh_frame@GLIBC_2.35 (for example) will not > > add dynamic linker features first implemented in glibc 2.35. > > I am not sure if I am following your concerns. We have an ELF feature, > like DT_RELR, which is tied to a glibc version. The binary with DT_RELR > will crash with the older glibcs. And you DON'T want such a binary with > a dependency on the required glibc version. Can you tell me why? You never want to test for versions to imply absence or presence of features. You want to test for the feature, or alternatively for an indication of said feature. Such indication could be the existence of a fake symbol (which can have a symbol version, no less), some flag mechanism (where to-be-defined flags would mean features), or suchlike. I find the idea of symbols the most intuitive one. DT_RELR binaries could require (from their .dynsym), say '_dl_have_relr', and glibc supporting it would provide that feature. Version checks always run into trouble vs. backports, and simply aren't the right tool. Ciao, Michael.