public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: "Carlos O'Donell" <carlos@redhat.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: gnu-gabi@sourceware.org, Binutils <binutils@sourceware.org>,
		GNU C Library <libc-alpha@sourceware.org>
Subject: Re: Dynamic tag assignment request: Disable symbol version coverage check
Date: Tue, 01 Jan 2019 00:00:00 -0000	[thread overview]
Message-ID: <CAEMqeSpMPc6f13qOLmc26wrb-PmivWj2EdbyG3_QiNBRm-dY5A@mail.gmail.com> (raw)
In-Reply-To: <87bluq6zmo.fsf@oldenburg2.str.redhat.com>

On Wed, Oct 9, 2019 at 5:23 AM Florian Weimer <fweimer@redhat.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
> 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.

      reply	other threads:[~2019-10-29 19:03 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-01  0:00 Florian Weimer
2019-01-01  0:00 ` Carlos O'Donell [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEMqeSpMPc6f13qOLmc26wrb-PmivWj2EdbyG3_QiNBRm-dY5A@mail.gmail.com \
    --to=carlos@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=fweimer@redhat.com \
    --cc=gnu-gabi@sourceware.org \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).