From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 469DF1F8C6 for ; Fri, 9 Jul 2021 16:37:18 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DFE75398703C for ; Fri, 9 Jul 2021 16:37:16 +0000 (GMT) Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 34CD838515F3 for ; Fri, 9 Jul 2021 16:37:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 34CD838515F3 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 0246530016BF for ; Fri, 9 Jul 2021 18:37:03 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 497084000CB1; Fri, 9 Jul 2021 18:37:03 +0200 (CEST) Message-ID: Subject: glibc 2.33.9000 version checks and in memory file name change From: Mark Wielaard To: libc-alpha@sourceware.org Date: Fri, 09 Jul 2021 18:37:03 +0200 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 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: , Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" Hi, valgrind is kind of special and does various things it really shouldn't do, but... There is one change in particular in 2.34 pre-releases that is causing us some headaches. It took a bit of time to understand that this innocent looking changes had an impact: * Previously, glibc installed its various shared objects under versioned file names such as libc-2.33.so. The ABI sonames (e.g., libc.so.6) were provided as symbolic links. Starting with glibc 2.34, the shared objects are installed under their ABI sonames directly, without symbolic links. This increases compatibility with distribution package managers that delete removed files late during the package upgrade or downgrade process. This has an impact on anything that uses in-process mapped file names. For example most programs using backtraces used to report something like: #0 0x00007fd73bdcbaea __GI___clock_nanosleep - /usr/lib64/libc-2.33.so #1 0x00007fd73bdd0d57 - 1 __GI___nanosleep - /usr/lib64/libc-2.33.so #2 0x000055988e913a00 - 1 main - /usr/bin/sleep #3 0x00007fd73bd2bb75 - 1 __libc_start_main - /usr/lib64/libc-2.33.so #4 0x000055988e913bbe - 1 _start - /usr/bin/sleep But now report: #0 0x00007f070b8a2c1a __GI___clock_nanosleep - /usr/lib64/libc.so.6 #1 0x00007f070b8a7997 - 1 __GI___nanosleep - /usr/lib64/libc.so.6 #2 0x000055657fbf0a00 - 1 main - /usr/bin/sleep #3 0x00007f070b7f57e0 - 1 __libc_start_call_main - /usr/lib64/libc.so.6 #4 0x00007f070b7f588c - 1 __libc_start_main_impl - /usr/lib64/libc.so.6 #5 0x000055657fbf0bb5 - 1 _start - /usr/bin/sleep Unfortunately valgrind suppressions are based on the file name reported in the backtrace when valgrind reports an issue. For example we have some standard suppressions like: { helgrind-glibc-io-xsputn-mempcpy Helgrind:Race fun:__GI_mempcpy fun:_IO_*xsputn* obj:*/lib*/libc-2.*so* } That tells to suppress an Helgrind Race condition if the backtrace originated for an in memory object file matching */lib*/libc-2.*so*. This suppression fails now since /usr/lib64/libc.so.6 doesn't match that pattern. I wonder if there are other programs which might depend on the in memory file name of glibc and might be impacted by this change. Now we can update our default suppressions and will do so. Unfortunately our current mechanism for doing that relies on a configure check for the glibc version. Specifically we check whether features.h defines __GLIBC__ __GLIBC_MINOR__ and construct the glibc version from that. But current development versions of glibc (like Fedora rawhides glibc-2.33.9000) still report __GLIBC_MINOR__ as 33. Is there a way to detect this is really 2.33.9000 aka almost 2.34? Or could you up the __GLIBC_MINOR__ already now that people are starting to ship test versions like 2.33.9000? Thanks, Mark