From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by sourceware.org (Postfix) with ESMTPS id 96EC83858410; Tue, 26 Oct 2021 15:52:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 96EC83858410 Received: by mail-pj1-x1033.google.com with SMTP id k2-20020a17090ac50200b001a218b956aaso2077046pjt.2; Tue, 26 Oct 2021 08:52:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NrMwkaoILn4nJ+NJ/rRM8lYTE4Ld/Jop7Wy7bR4t1Bk=; b=hvQaR8KNcCF81/KdZqlDMfGE85slbXSXdik8FG8YPBFOu11F7nYe2W8u67r/oafuma FHEI/10L6dYJOkojkNUOozfQ9NgpQVJoH11M1yK/38UTx5TGsB5xx46aFCeidVzLch1q zJomNyzGYAFlPDKDNFBG82PWummS7UQuHXnG+47OcOs4vBdI9/5Fh7p7EP2brXFlkQxP adrPwgsbmd9fRb+ptCafeLYiKcgFD6chHlOr+1lY5vqOsCpwgvWjZKha72B4W2bUGb3L 97HBVWIuqmQ4UyMkKF7ZhqtJPIdnD7OpVigIyGPMG6RQJaIG3NUZe0r4z1uS733OyPD9 FoMQ== X-Gm-Message-State: AOAM530qKMO9XPV4YPboUVHWRK7RL/h/DGdut7J5cpJtV2BW3KKKYbsJ +DPxGC+TViCuMRJ8qmfbrZweREFHJWZX2uxU1+c= X-Google-Smtp-Source: ABdhPJw6icDprXQkwXyKx6wssTCfmfEBvetAt6Fhr9Civ1bgFFRf0xW6vzccZFmkjV/hvXE+HQ/aY7lsiw/pElcWjXM= X-Received: by 2002:a17:903:1111:b0:13f:d1d7:fb67 with SMTP id n17-20020a170903111100b0013fd1d7fb67mr22518515plh.85.1635263525718; Tue, 26 Oct 2021 08:52:05 -0700 (PDT) MIME-Version: 1.0 References: <87zgqvq03g.fsf@oldenburg.str.redhat.com> In-Reply-To: <87zgqvq03g.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Tue, 26 Oct 2021 08:51:29 -0700 Message-ID: Subject: Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED To: Florian Weimer Cc: "H.J. Lu via Libc-alpha" , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3023.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 15:52:08 -0000 On Tue, Oct 26, 2021 at 8:26 AM Florian Weimer wrote: > > * H. J. Lu via Libc-alpha: > > > [hjl@gnu-cfl-2 elfvers-1]$ make x > > gcc -B./ -o x x.o glibc-2-minor-1.o > > [hjl@gnu-cfl-2 elfvers-1]$ ./readelf -n --version-info x > > Version symbols section '.gnu.version' contains 4 entries: > > Addr: 0x00000000004004ae Offset: 0x0004ae Link: 6 (.dynsym) > > 000: 0 (*local*) 2 (GLIBC_2.34) 3 (GLIBC_2.2.5) 1 (*global*) > > > > Version needs section '.gnu.version_r' contains 1 entry: > > Addr: 0x00000000004004b8 Offset: 0x0004b8 Link: 7 (.dynstr) > > 000000: Version: 1 File: libc.so.6 Cnt: 4 > > 0x0010: Name: GLIBC_2.38 Flags: none Version: 5 > > 0x0020: Name: GLIBC_2.35 Flags: none Version: 4 > > 0x0030: Name: GLIBC_2.2.5 Flags: none Version: 3 > > 0x0040: Name: GLIBC_2.34 Flags: none Version: 2 > > > > Displaying notes found in: .note.gnu.property > > Owner Data size Description > > GNU 0x00000040 NT_GNU_PROPERTY_TYPE_0 > > Properties: 1_glibc_2_needed: 2.35, 2.38 > > ... > > [hjl@gnu-cfl-2 elfvers-1]$ ./x > > ./x: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by ./x) > > ./x: /lib64/libc.so.6: version `GLIBC_2.35' not found (required by ./x) > > [hjl@gnu-cfl-2 elfvers-1]$ > > What's the intended use case? The intended use case is to add a glibc version dependency without referencing any symbols for the glibc version. > This proposal may conflict in spirit with the glibc proposal to support > preloadable symbol version (so you can add _dl_find_eh_frame@GLIBC_2.35 > to a glibc 2.28 installation, for example). So far, symbol versions Why will adding a glibc version dependency change the preload behavior? > have only been used as a quick check for ABI coverage that also works > with lazy binding. This doesn't look the right mechanism to me without > also bringing in new marker symbols, in which case the note is not > needed. The GNU_PROPERTY_1_GLIBC_2_NEEDED note can be removed from shared libraries and executables. > > The problem that linkers and loaders ignore unknown types should be > tackled in a different way, e.g. by flagging critical types in some way. > See: > > Critical program headers and dynamic tags > > This won't help the existing ld.so binaries which this proposal is addressing. -- H.J.