From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78026 invoked by alias); 29 Oct 2019 19:03:45 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 78013 invoked by uid 89); 29 Oct 2019 19:03:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=innovation, authorize, H*r:sk:mail-ed, HX-Received:906 X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Oct 2019 19:03:44 +0000 Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E37AD81F0E for ; Tue, 29 Oct 2019 19:03:42 +0000 (UTC) Received: by mail-ed1-f69.google.com with SMTP id o20so9347057edr.17 for ; Tue, 29 Oct 2019 12:03:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BJRNSMSg/MLEA4Zh6s4zlYR0IRSqkV90XLy32PeSWIs=; b=TawNwmnQptBmXsRVxo/gFfkAJj1x3neW46lYIG92fwAlg71mEogGjmvuEJgcrBKt8x rXYyapnHY8WCjUoxfclD8vwhK8MIpS8bbJo4tZ49Xr35Z/vjVEM2ZeXKuzw1QCQf/TWH Ruc826L3D6FBSX7RhKor1rGMtDJyAg8nFJCt+d3+29bkF2GP1kZU3htEVnUwA9GC3H1R wl9Yusdd/E2RhlEqSHB8JBaYM+EoXfh7rE/s1qN6tn10mIOyZccKHomdlFap9yZ7wN5T vIiQr39U/lFzy4IAXoSr82joGRWJVCGqZ6FFDBhfnaZT9xN/J15djngNhGWEC8X2qHRL 4VCA== X-Gm-Message-State: APjAAAWN9hWocegAvzj72uLVhS7cDsdPCr2Dh0dbroFG6IT2mBX9Y3pL Fmk/L47e+tjfIdNOyGk7xUX2nt08cFfgw4v0y8xa/pf2K+liaugezBzgopjicqNGEER92s9hfrb x582yz/GY50sYG/lANo8DKcXxL1E+lfahEw== X-Received: by 2002:a17:906:a981:: with SMTP id jr1mr4859800ejb.255.1572375821581; Tue, 29 Oct 2019 12:03:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqySOkaYGtmTSDOjq137RFT6GeCI4O7MB8GPTFj2niKU+teZrIvISmsfcpPLrdLh9a+Ps3oRgBennEamIE11E/M= X-Received: by 2002:a17:906:a981:: with SMTP id jr1mr4859761ejb.255.1572375821306; Tue, 29 Oct 2019 12:03:41 -0700 (PDT) MIME-Version: 1.0 References: <87bluq6zmo.fsf@oldenburg2.str.redhat.com> In-Reply-To: <87bluq6zmo.fsf@oldenburg2.str.redhat.com> From: "Carlos O'Donell" Date: Tue, 01 Jan 2019 00:00:00 -0000 Message-ID: Subject: Re: Dynamic tag assignment request: Disable symbol version coverage check To: Florian Weimer Cc: gnu-gabi@sourceware.org, Binutils , GNU C Library Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00001.txt.bz2 On Wed, Oct 9, 2019 at 5:23 AM Florian Weimer wrote: > I'd like to receive an assignment for a dynamic tag value which we will > use in the dynamic linker to disable the coverage check for symbol > versions. We don't have a GNU gABI governance process setup to authorize such tag requests. I propose that glibc takes the lead and proposes the tags they will use, gives it some time, say a week and then commits to the tag use. I will impose another rule though, we shall not request new tag allocations within a month of release of glibc. That is to say that reserving a new tag during the freeze window is something we should not do. You can reserve it much earlier and commit it later, but the process of reservation should have some space between it and the release, at least a month, to allow others to object before the tag value goes out into an official release. > This is what the coverage check does: For each verneed entry, it checks > that the name shared object (identified by its soname) implements all > the versions listed in the vernaux entries for the verneed entry. I > believe this check was added so that the loader can tell immediately at > load time if all the required symbols are present, even if lazy binding > is used. (Obviously, this requires proper symbol versioning practices, > and one cannot add a new symbol to an existing version once the shared > object has been released to the world.) That sounds correct to me. > A side-effect of this check is that it is currently impossible to use > LD_PRELOAD to load new symbol versions that come from linking to a newer > version of a shared object. The coverage check will not notice that the > version is provided by the preloaded object and will still fail. Correct, and that's quite limiting. > In contrast, if the glibc dynamic loader encounters the new dynamic tag > in any of the initially loaded objects, it will disable the version > coverage check. The idea is that a developer who builds an LD_PRELOAD > object can set the dynamic tag and add completely new symbol versions. > From a user perspective, it will look like just another preloaded > object. That sounds good to me. > I guess I'm looking for an assignment like this: > > #define DT_GNU_NOSYMVERCHECK 0x6ffffdf4 As a steward for the glibc project I accept the use of DT_GNU_NOSYMVERCHECK. Given that this has been posted on October 9th, and it's 20 days later, I think you can immediately use this constant in glibc. > This is GNU-specific because symbol versioning is a GNU innovation. > (Solaris has shared object versioning, but it is completely different, > despite version scripts sharing some syntactic similarities.) Agreed. Cheers, Carlos.