public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
* Re: Dynamic tag assignment request: Disable symbol version coverage check
  2019-01-01  0:00 Dynamic tag assignment request: Disable symbol version coverage check Florian Weimer
@ 2019-01-01  0:00 ` Carlos O'Donell
  0 siblings, 0 replies; 2+ messages in thread
From: Carlos O'Donell @ 2019-01-01  0:00 UTC (permalink / raw)
  To: Florian Weimer; +Cc: gnu-gabi, Binutils, GNU C Library

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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Dynamic tag assignment request: Disable symbol version coverage check
@ 2019-01-01  0:00 Florian Weimer
  2019-01-01  0:00 ` Carlos O'Donell
  0 siblings, 1 reply; 2+ messages in thread
From: Florian Weimer @ 2019-01-01  0:00 UTC (permalink / raw)
  To: gnu-gabi; +Cc: binutils, libc-alpha

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2019-10-29 19:03 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-01  0:00 Dynamic tag assignment request: Disable symbol version coverage check Florian Weimer
2019-01-01  0:00 ` Carlos O'Donell

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