From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) by sourceware.org (Postfix) with ESMTPS id C6E54385840F for ; Sun, 28 Nov 2021 07:02:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C6E54385840F Received: by mail-oo1-xc35.google.com with SMTP id w15-20020a4a9d0f000000b002c5cfa80e84so4693397ooj.5 for ; Sat, 27 Nov 2021 23:02:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=0pLMFo/IYRKbR4S9y9XyxqBMgCQuTwzNNq8bV/2cXV8=; b=bj5d2rYyF2p3RKUthYnlnhYjzwcmBH9KuB03TSFPbBA1IR4h0cp5S1zV+Zlfe0BOov HeJ5E/swmZT/LGPMwN8Fr/OvDYpGZHnbWimOXtk8Te5qDa6afIbCWg++XvAZpv2k273m jB65u8Ujx8b7Xb/MuCmMcVJLFO23QEdeZxhQgkVEJwffUtSm1LDOI7VPGJfEdQKk35Ij QT//iVV3+AfjziFSnoLcbHw9Vam4Qm8pjHjiVRcoisEMom96YE9k5hGdlTL4kK07KFTx FDlI1eusQnNKziwJBlJbTFzkrwN9XQAWUbqjGqidfC6dOccRacUqARTgnnAzojTNGVhm 6wSg== X-Gm-Message-State: AOAM532BE4b/ZdWKnGhfLf0ojTS4dw8DWrw/27E9Pvrsn8NIBYhnB8Da NMTG2U+ubQtk2PC1NH6S0vC3jDhct5QyyVZ9B+s1OfIr+9Q= X-Google-Smtp-Source: ABdhPJyUyWCXaaG118MA17x3gY9JYMx7/wKg1T0c06JWLfp4zxEvBl4OSqur8AfFypn7Q+JeOiVcWbkEWZKU9KYq7GE= X-Received: by 2002:a4a:1d82:: with SMTP id 124mr26703441oog.91.1638082920589; Sat, 27 Nov 2021 23:02:00 -0800 (PST) MIME-Version: 1.0 Reply-To: mtk.manpages@gmail.com From: "Michael Kerrisk (man-pages)" Date: Sun, 28 Nov 2021 08:00:00 +0100 Message-ID: Subject: (Dynamic linker) semantics of version script inheritance/dependency To: libc-help Cc: Michael Kerrisk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2021 07:02:03 -0000 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))? =3D=3D 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 __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 <=3D=3D=3D=3D not present if lib built using S= cript_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 =E2=80=98VERS_1.2=E2=80=99. This node= depends upon =E2=80=98VERS_1.1=E2=80=99. The script binds the symbol =E2=80=98foo2= =E2=80=99 to the version node =E2=80=98VERS_1.2=E2=80=99. ]] 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 --=20 Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/