public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: gnu-gabi@sourceware.org
Cc: binutils@sourceware.org, libc-alpha@sourceware.org
Subject: Dynamic tag assignment request: Disable symbol version coverage check
Date: Tue, 01 Jan 2019 00:00:00 -0000	[thread overview]
Message-ID: <87bluq6zmo.fsf@oldenburg2.str.redhat.com> (raw)

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.

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.)

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.

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.

I guess I'm looking for an assignment like this:

#define DT_GNU_NOSYMVERCHECK 0x6ffffdf4

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.)

Thanks,
Florian

             reply	other threads:[~2019-10-09  9:23 UTC|newest]

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

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=87bluq6zmo.fsf@oldenburg2.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=binutils@sourceware.org \
    --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).