This is the mail archive of the
mailing list for the glibc project.
Re: Dynamic tag assignment request: Disable symbol version coverage check
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: gnu-gabi at sourceware dot org, Binutils <binutils at sourceware dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 29 Oct 2019 15:03:29 -0400
- Subject: Re: Dynamic tag assignment request: Disable symbol version coverage check
- References: <firstname.lastname@example.org>
On Wed, Oct 9, 2019 at 5:23 AM Florian Weimer <email@example.com> 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
We don't have a GNU gABI governance process setup to authorize such
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
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.)