public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
* (Dynamic linker) semantics of version script inheritance/dependency
@ 2021-11-28  7:00 Michael Kerrisk (man-pages)
  0 siblings, 0 replies; only message in thread
From: Michael Kerrisk (man-pages) @ 2021-11-28  7:00 UTC (permalink / raw)
  To: libc-help; +Cc: Michael Kerrisk

Hello all,

(This is a detail of ld.so I've always felt like I only vaguely
understood, but now I've decided that I really don't understand.)

Summary: do the presence/absence of version dependency tags in a
version node of a version script make any difference to the behavior
of the dynamic linker (or for that matter, ld(1))?

==

Consider these two version scripts that might be used to build a
symbol-versioned shared library:

    # Script_1
    VER_1 {
            global: xyz;
            local:  *;
    };

    VER_2 {
            global: pqr;
    } VER_1;          # VER_2 is "dependent" on VER_1

versus

    # Script_2
    VER_1 {
            global: xyz;
            local:  *;
    };

    VER_2 {
            global: pqr;
    };

The only difference is the lack of a dependency "VER_1" in the "VER_2"
clause of Script_2.

Let's suppose library source code such as:

[[
#include <stdio.h>
__asm__(".symver xyz_new,xyz@@VER_2");
__asm__(".symver xyz_old,xyz@VER_1");

void xyz_old(void) { printf("v1 xyz\n"); }
void xyz_new(void) { printf("v2 xyz\n"); }
void pqr(void) { printf("v2 pqr\n"); }
]]

If I build a library in the usual way, the only difference that I can
see (using "readelf -a") is in the .gnu.version_d section:

[[
Version definition section '.gnu.version_d' contains 3 entries:
 Addr: 0x00000000000004f0  Offset: 0x0004f0  Link: 5 (.dynstr)
  000000: Rev: 1  Flags: BASE  Index: 1  Cnt: 1  Name: lib_svinh_v2_v1.so
  0x001c: Rev: 1  Flags: none  Index: 2  Cnt: 1  Name: VER_1
  0x0038: Rev: 1  Flags: none  Index: 3  Cnt: 2  Name: VER_2
  0x0054: Parent 1: VER_1    <==== not present if lib built using Script_2
]]

There seems to be no different effect for the version markings on
symbols (xyz and pqr) in the dynamic symbol table, and therefore
(presumably) no difference in effect when the dynamic linker does
run-time symbol relocation.

The ld(1) manual is pretty vague here[1], saying just:

[[
The easiest way to demonstrate the version script language is with a
few examples.

VERS_1.1 {
    global:  foo1;
    local: old*; original*; new*;
};

VERS_1.2 {
    foo2;
} VERS_1.1;

...

Next, the version script defines node ‘VERS_1.2’. This node depends
upon ‘VERS_1.1’. The script binds the symbol ‘foo2’ to the version
node ‘VERS_1.2’.
]]

But in the above, the meaning of "depends upon" is never explained,
AFAICS. (The SUN Linkers and Libraries Guide[2] seems also similarly
vague, talking of "inheritance", but likewise never really explaining
the term.)

So, my question really is: what does version tag "dependency" (or
"inheritance") really mean (if anything!)?

And in particular, does the presence/absence of the version dependency
tag ("} VER_1;" above)"
* Have any influence on the semantics of the "local:*" and "global:"
clauses and the version tag markings that are attached to symbols in
the dynamic symbol table? (From my experiments so far, the answer
seems to be "no".)
* Have any other influence on the behavior of the dynamic linker?

Thanks,

Michael

[1] https://sourceware.org/binutils/docs/ld/VERSION.html
[2] https://docs.oracle.com/cd/E19683-01/817-3677/817-3677.pdf

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2021-11-28  7:02 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-28  7:00 (Dynamic linker) semantics of version script inheritance/dependency Michael Kerrisk (man-pages)

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