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: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-4.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (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 F22701F8C6 for ; Wed, 14 Jul 2021 16:55:52 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D3BEF398643B for ; Wed, 14 Jul 2021 16:55:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D3BEF398643B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1626281751; bh=zHqXw1j5lSDZUn3c9OfHrO850Wj/4YRfN3NpIjapI3w=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=JRYNMKyvY8lTje2sVjgDTheqLMS/SDrmjZwpQyNvpxtNVN7+BFp2xEFfXENEcgCBl heFa4vmZu3DxT4J9fop2dVIc/UQAT9Gr++29IhCpIM5td8rqezspquEy/x+tjS49La 9G/72p2P6bLjus01QF8w/dWi3qBN+SL+6jyZ9q54= Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by sourceware.org (Postfix) with ESMTPS id 8D48D3848417 for ; Wed, 14 Jul 2021 16:55:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8D48D3848417 Received: by mail-pj1-x102e.google.com with SMTP id p4-20020a17090a9304b029016f3020d867so2117866pjo.3 for ; Wed, 14 Jul 2021 09:55:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zHqXw1j5lSDZUn3c9OfHrO850Wj/4YRfN3NpIjapI3w=; b=n/NSDT/vG1OWNhKcd09cD1BZl9RF36oiQSmrxd8t40PQ/YCbNf1KguNF2YfsL2Zlzg mEs6sK1GfImAMWvf+CPqeiFlwJ4y3PQfflfef+4/0ZjAoWw9b4qiGcdjzLSqZJP18TAk S+OCOxkljEgPRQFgRZqRoIByOpBKaHBa1ynPKpQ9OjYCn+Yer/nD2HeRqlJlzqhb2mq8 bs2s+eeTUCd5ar/SWsn4WCTF9t/FWs0y3Z/8vYp7O/JkrfRaIqMoHHBtGMNZ6qb7jwoV Vx7F50WuBnvnio5DvlSCgjuNEIj8BnxLTjZ/Ak/slQcCwANz7xY23w08PlsufZeEf3T4 +Kwg== X-Gm-Message-State: AOAM533402ikFbLrjuxWeDCUlmON+svCadGeYKx1uPW7K80SKp5OP6iS f/3cC7CxPTU35915tTfXBIQQCV//amgRKg== X-Google-Smtp-Source: ABdhPJw+OwxLBKeWsAtFMQrIVhT7B52jfv+UH8b+IpHugMDXt5vv1Cz0SzbFb+OcVXgNIM+4PPEDTw== X-Received: by 2002:a17:903:234a:b029:12b:45b8:a773 with SMTP id c10-20020a170903234ab029012b45b8a773mr3056663plh.6.1626281730559; Wed, 14 Jul 2021 09:55:30 -0700 (PDT) Received: from [192.168.1.108] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id 25sm5024100pjg.9.2021.07.14.09.55.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jul 2021 09:55:30 -0700 (PDT) Subject: Re: glibc 2.33.9000 version checks and in memory file name change To: libc-alpha@sourceware.org, Mark Wielaard References: Message-ID: <4c689db6-a8c3-9975-48b3-6828bdcdb152@linaro.org> Date: Wed, 14 Jul 2021 13:55:27 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: , From: Adhemerval Zanella via Libc-alpha Reply-To: Adhemerval Zanella Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 09/07/2021 13:37, Mark Wielaard wrote: > 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. 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). > > 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? Because you could use use something like "libc*(-2.[0-9]*).so*" if you can use a glob-like with some gnu extensions. > > 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. Usually we do follow the release procedure to just bump de version to 2.34 once the release is actually done.