From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by sourceware.org (Postfix) with ESMTPS id 8DE603857C59 for ; Wed, 5 May 2021 16:55:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8DE603857C59 Received: by mail-qt1-x82f.google.com with SMTP id o1so1728372qta.1 for ; Wed, 05 May 2021 09:55:14 -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=QCqD/+WvJmQXitjQGpWdmgrSF/6vl04/fOnDOXWL2Ck=; b=rYe6Vx3ZPGHo5afCdxDM0AZfqsVrgjSDIo22nICjE1Ce1z7Fp/wKiwSiMgmFhmTw9F CP2e+kLu7O/wO+J5tp5rZ99PPqwazGTDut/yNrNgaxSC2MI5iRaTKBi7dVNICsOAH/C7 LeYPlYjR/KfTkH0zOyHInEA8g5HnCSksJrmWMGfi+P6tjqWamredf000gxQYhBTdYZfs Gd7QKuf5maPs2LDcEzfnuRGva3sFgmuRKgeMyCCalg1pNnQn8//kXL6yvJGRH8BYxVkO TDbZyMml8kiU5nBQlnHbmSuqJt0uUm67SHQ3ah0QoxQf58+a2Z6A2rlDtPaFgKtx6TvY USFA== X-Gm-Message-State: AOAM531Ffn7pIgqo+Fu2E8bUZ1htelpEZrp4/khgvALGZ0EFuTO4Dngi IWdLO3sqT6qkwNkPy8wLEns3fw== X-Google-Smtp-Source: ABdhPJyREkLxOL8+7g1ThHPDXqbrbSIj49gJVwTi/5bybfVUWXXw+8+NSnVhdfsHynq2FSy4DKapCg== X-Received: by 2002:ac8:7a67:: with SMTP id w7mr16469815qtt.20.1620233714165; Wed, 05 May 2021 09:55:14 -0700 (PDT) Received: from [192.168.1.4] ([177.194.37.86]) by smtp.gmail.com with ESMTPSA id h65sm13872335qkc.128.2021.05.05.09.55.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 May 2021 09:55:13 -0700 (PDT) Subject: Re: [PATCH v2] elf: Implement filtering of symbols historically defined in libpthread To: Florian Weimer , "H.J. Lu" Cc: GNU C Library , Andreas Schwab References: <87eeelfg77.fsf@oldenburg.str.redhat.com> <9a5b4cec-15e6-8c89-9d01-1f2d78deb804@linaro.org> <87im3xdvah.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: <243dfbc9-b23b-5ed7-f720-6b7ead9af241@linaro.org> Date: Wed, 5 May 2021 13:55:11 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87im3xdvah.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_BLACK autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Wed, 05 May 2021 16:55:15 -0000 On 05/05/2021 13:01, Florian Weimer wrote: > * H. J. Lu: > >> On Wed, May 5, 2021 at 8:33 AM Adhemerval Zanella via Libc-alpha >> wrote: > >>> On 05/05/2021 10:44, Florian Weimer via Libc-alpha wrote: >>>> Definitions of these symbols in libc expose bugs in existing binaries >>>> linked against earlier glibc versions. Therefore, hide these symbols >>>> for old binaries. >>>> >>>> The symbol list in sysdeps/nptl/dl-pthread-weak.c contains some >>>> symbols which have not been moved yet, but that is harmless because >>>> the function is only invoked if the symbol is found in libc.so. >>> Can we postpone this fix until we get all the symbols from libpthread >>> properly moved? I really dislike the symbol filter list, it is error >>> prone and add unnecessary code size. >> >> Agreed. We should just check one symbol, version, ABI note or property. >> It shouldn't be too hard to do. > > My patch checks for the presence of libpthread.so.0 and GLIBC_2.34. I > think the latter corresponds to your “one check” rule. (We obviously > need to disable all the magic in case libpthread.so.0 is present because > then the symbols would be bound even on older glibc versions.) > > But that is not why my patch contains a symbol table: Once we detect an > old binary, we need to treat certain symbols differently. There are > actually unversioned weak references to pthread_mutex_lock out there. > pthread_mutex_lock@@GLIBC_2.0 has existed in libc.so.6 for a long time, > so we need to bind such weak references to a definition. In contrast, > __pthread_mutex_lock@@GLIBC_2.0 only existed in libpthread.so.0 in glibc > 2.33 and earlier. This is why there is a table of magic symbols. It's > not to detect old binaries, it's there to record certain symbols which > were historically part of libpthread.so.0 only. That is a property of > past binaries; as such it won't change with future glibc versions. > That's why I think we need to encode that symbol set somewhere. And a > sorted table is a low-tech version to implement that. I am trying to understand which scenario the _dl_pthread_hidden_symbol is required where the first part of dl_pthread_hide_symbol can't find that the symbol should be hidden.