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=-3.9 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_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 6653E1F5AE for ; Mon, 19 Jul 2021 11:50:42 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 627353946C32 for ; Mon, 19 Jul 2021 11:50:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 627353946C32 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1626695441; bh=eU00FRepnBTQcmcx9c+tT7sjnFsSIm+OAs0PaKey+Ms=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=blj2dAyJyWYwMTqzMFdC0b9Lho5wYZ05yGJhaQhRgj6dr1NA2SZMj6j4giSNzuG0j zeD9njjsXieyvkH3e0y5i5smtk+fnARnNY1It5XFC9q7KFp6GUPVNJ8EsTqRlG1OrI tdJSDsK6ikVkDl8ZLgN4c2UgEKDPtIw7cJAQ8Q2Y= Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by sourceware.org (Postfix) with ESMTPS id 82DF13945C22 for ; Mon, 19 Jul 2021 11:49:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 82DF13945C22 Received: by mail-pj1-x1035.google.com with SMTP id jx7-20020a17090b46c7b02901757deaf2c8so11951732pjb.0 for ; Mon, 19 Jul 2021 04:49:58 -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:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eU00FRepnBTQcmcx9c+tT7sjnFsSIm+OAs0PaKey+Ms=; b=T2YUXAj/1eUxlNjoEUsu8tXFcDt/MF2UEX7q+At3GS/+K783Kii3rVvYkaLvgi+Gn+ xGPyYZjktLQDsF6LdHCLVSYTc3qZwlsXdtRtyjZ447kcKY8glEcSoa8H3hRzxjMyDniY obk7Wlnu4rglh74VF3KELPznkkZJITme23v58b8h5sOX79HP8nkYEy36J9QpE/2hkfGO g0Borepq0lxa3Jjw6m7EQdYYfQ0n/W/op4gXH/d9v8Kg8XO+M7wJ+CyREDt6VmbbkFnK PbUSxJPaqR3E2f6Eghlx6ZD4A7mdsnUcgVtnWmsaIkkt1uRwqEZzBjckqRu2XP290V8d zvJA== X-Gm-Message-State: AOAM5303op9JuWDBBpLZ0mPhRNER/AhDBf8raQ0sRwJDuogvqlA8hRYV XB+B3+/xRSk4AsQknF5mxSDtLPa4NdIpFw== X-Google-Smtp-Source: ABdhPJwhIZG3CmvyqHNfTkxS/ZkribKYEjOseDIHvKNGlwQv0/mL3ohyTy8WTfpuEpVheHqPXUvtwg== X-Received: by 2002:a17:90a:b78d:: with SMTP id m13mr19107327pjr.60.1626695397412; Mon, 19 Jul 2021 04:49:57 -0700 (PDT) Received: from ?IPv6:2804:431:c7ca:1133:c8a4:b05d:5ba9:3665? ([2804:431:c7ca:1133:c8a4:b05d:5ba9:3665]) by smtp.gmail.com with ESMTPSA id 72sm22629634pgd.10.2021.07.19.04.49.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jul 2021 04:49:57 -0700 (PDT) Subject: Re: glibc 2.33.9000 version checks and in memory file name change To: Mark Wielaard , Carlos O'Donell References: <4c689db6-a8c3-9975-48b3-6828bdcdb152@linaro.org> Message-ID: Date: Mon, 19 Jul 2021 08:49:54 -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 Cc: libc-alpha@sourceware.org Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 19/07/2021 06:18, Mark Wielaard wrote: > 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... We really care about ABI stability and since this is accomplished by setting the expected soname on DT_NEEEDED, I think adding another constrain, such the installed filename, does not really add much here. The potential breakage is minimum imho and could be mitigated by using a more expressive filter (such as the one I suggested) if filename is really important by the project. > >>> 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. > I don't have a strong opinion, maybe we could bump it on slushy freeze that usually happens 4 weeks prior release. Carlos, what do you think about changing it to the next release?