From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) by sourceware.org (Postfix) with ESMTPS id 63CA33858C27 for ; Wed, 5 May 2021 18:06:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 63CA33858C27 Received: by mail-qv1-xf2d.google.com with SMTP id g17so1699533qvl.9 for ; Wed, 05 May 2021 11:06:55 -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=QvXR/mYKmR7+qGcN5mexi6GVeH84rloxdpka9481Jgo=; b=PyEgYCWUorlrgeYMxqy49jrWNynXVyd52Mhh1d3tPiMojDd7WanoHd562Lpc0f3Nka knJgiif3qBIhx8vduWZPpfx1YizwE6/VZsnMKWDZyQOg1+aATxZL6jumr98eMt7UNxGv PvYEld4aX5+coQ329T2XtxvEsiAIR24e/UonepX0fKh9saXWwHL6xEd4c8KjNMjg2djg IyA2SBsmyS763RJ9CDXY4AKsPihyA7c/LDhDQtSzoxTfSUPv9RGBkzG9WQOAMPTr0Kg+ +hrVShy1FxfxKQ2h+Hko7b2/MAj0PJjLHwSVCl6EHM8Xq11AJby0h4HQQ5iR5mSmJzXC Duwg== X-Gm-Message-State: AOAM530ZK7mUrPsNPbh+kjqpyC7yH4FRMwj3ZeymsAZ00Y8mue6rJRq0 w+RvL+/cAIAlsAF1spKo7ru41A== X-Google-Smtp-Source: ABdhPJxnwu6E3bcR+IhBwAmShA6OmfZMXEJJpoBk20mMlmhTsCmmOVGzeP2QpjwGsl5SHdt44WBCFA== X-Received: by 2002:a0c:bf4b:: with SMTP id b11mr12973674qvj.11.1620238014901; Wed, 05 May 2021 11:06:54 -0700 (PDT) Received: from [192.168.1.4] ([177.194.37.86]) by smtp.gmail.com with ESMTPSA id d6sm5496315qtn.52.2021.05.05.11.06.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 May 2021 11:06:54 -0700 (PDT) Subject: Re: [PATCH v2] elf: Implement filtering of symbols historically defined in libpthread To: Florian Weimer Cc: "H.J. Lu" , 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> <243dfbc9-b23b-5ed7-f720-6b7ead9af241@linaro.org> <87eeeldrp4.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: <3740a7af-3315-9de9-f680-af7e659b4b4e@linaro.org> Date: Wed, 5 May 2021 15:06:51 -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: <87eeeldrp4.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 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 autolearn=ham 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 18:06:56 -0000 On 05/05/2021 14:19, Florian Weimer wrote: > * Adhemerval Zanella: > >>> 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. > > glibc 2.34 defines both pthread_mutex_lock@GLIBC_2.0 and > __pthread_mutex_lock@GLIBC_2.0 in libc. glibc 2.33 and earlier only > defined pthread_mutex_lock@@GLIBC_2.0 in libc. > > There are old binaries out there that contain unversioned weak > references to pthread_mutex_lock or to __pthread_mutex_lock, without > linking against libpthread. To preserve backwards compatibility, > pthread_mutex_lock must be bound to the function symbol in libc, but > __pthread_mutex_lock must not be bound. >From where unversioned weak __pthread_mutex_lock come from and how are they generated? It seems another interface abuse and I am not sure if we should keep backwards compatibility for double underscore symbols. > > That's why I think we need to tell the two symbols apart. There are of > course many ways to encode the difference. A name-based check seemed > the most straight-forward approach to me. It is an implementation > detail. With link editor support or binary rewriting, we could come up > with alternative approaches (e.g., a bitmap containing a bit for each > symbol table entry). I'm not sure if that would result in code size > savings though. > > Thanks, > Florian >