From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id BF591393F835 for ; Mon, 19 Jul 2021 09:18:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BF591393F835 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 reform (77-167-121-15.hybrid.kpn.net [77.167.121.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id DD45F300066F; Mon, 19 Jul 2021 11:18:11 +0200 (CEST) Received: by reform (Postfix, from userid 1000) id C362E2E800CB; Mon, 19 Jul 2021 11:18:10 +0200 (CEST) Date: Mon, 19 Jul 2021 11:18:10 +0200 From: Mark Wielaard To: Adhemerval Zanella Cc: libc-alpha@sourceware.org Subject: Re: glibc 2.33.9000 version checks and in memory file name change Message-ID: References: <4c689db6-a8c3-9975-48b3-6828bdcdb152@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4c689db6-a8c3-9975-48b3-6828bdcdb152@linaro.org> X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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: Mon, 19 Jul 2021 09:18:16 -0000 Hi, On Wed, Jul 14, 2021 at 01:55:27PM -0300, Adhemerval Zanella wrote: > On 09/07/2021 13:37, Mark Wielaard wrote: > > 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. > > I am not sure, but relying on such naming scheme is fragile in principle: > although the installation did use the embedded the version in the > installed filename nothing preventes the distribution to rename it to > something complete different (since the DT_NEEDED will still point to > libc.so.6). Yes, it would be nicer to have used the so name, but people are more familiar with the actual file name. It also used to be more architecture independent. Because of the symlinks ld.so was named the same on all arches. I certainly understand this was just by accident and we shouldn't have relied on it, but... > > 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. > > What kind of regular expression does valgrind suppression mechanism > support? Does it mimic the shell expansion used on glob(), for instance, > or is it something more restrict? It only knows about * (zero or more) and ? (zero or one) chars. > > 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? > > We now moved all libpthread/librt/libdl symbols to libc.so, so if you > must detect 2.34 glibc you may try use pthread_create without linking > to -lpthread. Thanks, that is a nice check. I used that for now. https://bugs.kde.org/show_bug.cgi?id=439590 > Usually we do follow the release procedure to just bump > de version to 2.34 once the release is actually done. Understood, and it is too late to change that for this release. But maybe for the next features.h could be changed at the freeze point instead of at release? Then people will test against the actual release number. Thanks, Mark