From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) by sourceware.org (Postfix) with ESMTPS id 4488A3A4E849 for ; Wed, 5 May 2021 18:19:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4488A3A4E849 Received: by mail-ot1-x330.google.com with SMTP id d3-20020a9d29030000b029027e8019067fso2513762otb.13 for ; Wed, 05 May 2021 11:19:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7bp4h/p9HXaqgHl0w1URej3lVzpzfcn03xjwhzZn/Ng=; b=EkimnNZWWh8TdVzN6mM94TsmIzw25MKiRQc961M4fePo0XgmF9VChweDAa1QEtwDqm 7QCM+yu8NdzuxvZEoNPKZmASF0Zv5m9Qci2cHUvDb37q096MKft4M7VZ89Pk2r66UYzl 8LkfKP4aptU5gQzB1RY0/pjIElo+Udw/HQcAO8oUSCzlCuCFAogiqinDWa2RpSmyJDkd 053TnwH4H5ACS+Smiriec2x7+bvjmpyT9iF1e6JJwtCO7EaASfOUxGmpnZu3InHIpkpb DTvk6wAn1T1gBJLgTgxPimFRWj551PzpJaohrsMaM+UpYY0knPIaJTM4r+TgWuJQjE68 1IdA== X-Gm-Message-State: AOAM533TtLGE+ttC6XBpcs7drjrE8H0GROBRWdx6tuvBl+09BUOvCfDX f6JDQUwk8ArW/iM8fAmo+931YbA5zSdLOvJ2wT0= X-Google-Smtp-Source: ABdhPJyULgfYOaj1MHjEEUEItTGb8K8FtflYO4p3drZ6s/ifZQdNtNIXJmMFRI7zbaisLIlSXO80Nr8feelkwAnHjvY= X-Received: by 2002:a05:6830:2244:: with SMTP id t4mr8207152otd.125.1620238748710; Wed, 05 May 2021 11:19:08 -0700 (PDT) MIME-Version: 1.0 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> <3740a7af-3315-9de9-f680-af7e659b4b4e@linaro.org> <87o8dpavx3.fsf@oldenburg.str.redhat.com> In-Reply-To: <87o8dpavx3.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Wed, 5 May 2021 11:18:32 -0700 Message-ID: Subject: Re: [PATCH v2] elf: Implement filtering of symbols historically defined in libpthread To: Florian Weimer Cc: Adhemerval Zanella , GNU C Library , Andreas Schwab Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3028.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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:19:10 -0000 On Wed, May 5, 2021 at 11:15 AM Florian Weimer wrote: > > * Adhemerval Zanella: > > > 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. > > I can drop the __ symbols if you want. With the string table, we can > add more symbols again if needed. > > Most of the unversioned weak __pthread_mutex_lock references I have > actually come from our __libc_lock_lock macro. (They are now strong > references obviously.) However, someone copied that coding pattern into > the old nss_ldap module. This suggests that there could be other cases. Why can't we just hide symbols for undefined, weak, unversioned references from the old binaries? -- H.J.