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: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 98E201F5AE for ; Wed, 28 Apr 2021 02:14:10 +0000 (UTC) Received: from localhost ([::1]:39120 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lbZiL-0007Xb-Pn for normalperson@yhbt.net; Tue, 27 Apr 2021 22:14:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39772) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lbZiI-0007XS-G7 for bug-gnulib@gnu.org; Tue, 27 Apr 2021 22:14:06 -0400 Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]:43763) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lbZiG-0002sQ-M6 for bug-gnulib@gnu.org; Tue, 27 Apr 2021 22:14:06 -0400 Received: by mail-ot1-x32e.google.com with SMTP id u21-20020a0568301195b02902a2119f7613so10222616otq.10 for ; Tue, 27 Apr 2021 19:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=T36/trJjuKaAdXoMbGW7w1rKLTeYzzZDAtsY5AfDh0M=; b=Ts2UoXPYviaFC9qRD4qk8GoLMfGCyoVmeKVg/WWINvvZAo496zdIxWLMnEtHz3i2LW kOxPS7dZoaGXjnk+T0p48CQ+xTyED/qoaQcsv5IS5syI38e5efL0Nh5jLKivSxi4u3V0 8PYb2q/UI+yJoX3B6mQKpYSYooNqStGQv0PEB9Nchx879EAV8MxvOWH2t1nGCZd1qVv0 DRuJv50eHvs1WiRJxfG+eflFTwefty/RESQQpQrU0T3daqYX57PcWF58PrQtrJmw44py I0VW3Lg8yKgVcx/DOXqHMB2DmwlQdsi+r3pHD1nBLtyeLFczz6D/QObqnHmKAOMSv25n 0U+w== 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:content-transfer-encoding; bh=T36/trJjuKaAdXoMbGW7w1rKLTeYzzZDAtsY5AfDh0M=; b=j7vbmCmIJtDziVNHQ08+bxOdBNwMRIMJLAP2VjFftQmogR2lyh9XORqMivr6NoqaBe cRqdCm47KniWTAjKSpfeumqEOOZg+YQq8DRFg+eAh7YhEhuHwrwF1zbqFGM8WWCvdGJ+ 1VSLg71SsaRsQsV4hZkF+0W0t7PY8LejcKVQe2dCMmgON80+uzHI83LGs4V67wCXtvNS iOykYJ27iZGHX9iBbXDgeUUWH6QRPqaavOt/7Ps4QKU//+IjlJznewCGhcEpIPwYr0qa 6YUMkBryUXwkPGko7TKSHVaWa6LW+MzE7WTzsJd9eCXktQrBn+g8GEv0EhUM/MjxEPpS fVlA== X-Gm-Message-State: AOAM5339Ds6+JM7uHx6mUOgbD79w+o3yh3ZIeiVPO2XPtUvJYLZZKKGL IzwcM1ykLPEoV7EtvmmaqnUQU3Sf4bX6pJIav0g= X-Google-Smtp-Source: ABdhPJwMd8vzGLlhcZ8+J11mS7wsrv+wchSlY2mdHqc/BEYwI19hzFQwChIdGbJv3Eg2dGLOKi7li7128PVlieTlPpY= X-Received: by 2002:a05:6830:1e2f:: with SMTP id t15mr656139otr.125.1619576043597; Tue, 27 Apr 2021 19:14:03 -0700 (PDT) MIME-Version: 1.0 References: <87o8e0p92r.fsf@oldenburg.str.redhat.com> <87fszc8a1z.fsf@igel.home> <87eeewnfzw.fsf@oldenburg.str.redhat.com> <1680226.UWtE2gOZdF@omega> In-Reply-To: From: "H.J. Lu" Date: Tue, 27 Apr 2021 19:13:27 -0700 Message-ID: Subject: Re: Undefined use of weak symbols in gnulib To: Bruno Haible Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::32e; envelope-from=hjl.tools@gmail.com; helo=mail-ot1-x32e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Weimer , GNU C Library , Andreas Schwab , bug-gnulib@gnu.org, Binutils Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On Tue, Apr 27, 2021 at 7:10 PM H.J. Lu wrote: > > On Tue, Apr 27, 2021 at 6:57 PM Bruno Haible wrote: > > > > Hi Florian, > > > > > Here's a fairly representative test case, I think. > > > > > > #include > > > #include > > > > > > extern __typeof (pthread_key_create) __pthread_key_create __attribute= __ ((weak)); > > > extern __typeof (pthread_once) pthread_once __attribute__ ((weak)); > > > > > > void > > > f1 (void) > > > { > > > puts ("f1 called"); > > > } > > > > > > pthread_once_t once_var; > > > > > > void __attribute__ ((weak)) > > > f2 (void) > > > { > > > if (__pthread_key_create !=3D NULL) > > > pthread_once (&once_var, f1); > > > } > > > > > > int > > > main (void) > > > { > > > f2 (); > > > } > > > > > > Building it with =E2=80=9Cgcc -O2 -fpie -pie=E2=80=9D and linking wit= h binutils 2.30 > > > does not result in a crash with LD_PRELOAD=3Dlibpthread.so.0. > > > > Thank you for the test case. It helps the understanding. > > > > But I don't understand > > - why anyone would redeclare 'pthread_once', when it's a standard POS= IX > > function, > > - why f2 is declared weak, > > - why the program skips its initializations in single-threaded mode, > > - why libpthread would be loaded through LD_PRELOAD or dlopen, given > > that the long-term statement has been that declaring a symbol weak > > has no effect on the dynamic linker [1][2][3][4]? > > > > How about the following test case instead? > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > #include > > #include > > > > #pragma weak pthread_key_create > > #pragma weak pthread_once > > > > void > > do_init (void) > > { > > puts ("initialization code"); > > } > > > > pthread_once_t once_var; > > > > void > > init (void) > > { > > if (pthread_key_create !=3D NULL) > > { > > puts ("multi-threaded initialization"); > > pthread_once (&once_var, do_init); > > } > > else > > do_init (); > > } > > > > int > > main (void) > > { > > init (); > > } > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > $ gcc -Wall -fpie -pie foo.c ; ./a.out > > initialization code > > > > $ gcc -Wall -fpie -pie foo.c -Wl,--no-as-needed -lpthread ; ./a.out > > multi-threaded initialization > > initialization code > > > > What will change for this program with glibc 2.34? > > > > Bruno > > > > [1] https://sourceware.org/legacy-ml/libc-hacker/2000-06/msg00029.html > > [2] https://www.akkadia.org/drepper/dsohowto.pdf page 6 > > [3] https://stackoverflow.com/questions/21092601/is-pthread-in-glibc-so= -implemented-by-weak-symbol-to-provide-pthread-stub-functi/21103255 > > [4] https://stackoverflow.com/questions/20658809/dynamic-loading-and-we= ak-symbol-resolution > > > > Does x86 show the same issue? I fixed several undefined weak symbol > bugs on x86: > > https://sourceware.org/bugzilla/show_bug.cgi?id=3D19636 > https://sourceware.org/bugzilla/show_bug.cgi?id=3D19704 > https://sourceware.org/bugzilla/show_bug.cgi?id=3D19719 > > with a linker option: > > 'dynamic-undefined-weak' > 'nodynamic-undefined-weak' > Make undefined weak symbols dynamic when building a dynamic > object, if they are referenced from a regular object file and > not forced local by symbol visibility or versioning. Do not > make them dynamic if 'nodynamic-undefined-weak'. If neither > option is given, a target may default to either option being > in force, or make some other selection of undefined weak > symbols dynamic. Not all targets support these options. > > Alan extended the fix to PPC: > > commit 954b63d4c8645f86e40c7ef6c6d60acd2bf019de > Author: Alan Modra > Date: Wed Apr 19 01:26:57 2017 +0930 > > Implement -z dynamic-undefined-weak > > -z nodynamic-undefined-weak is only implemented for x86. (The sparc > backend has some support code but doesn't enable the option by > including ld/emulparams/dynamic_undefined_weak.sh, and since the > support looks like it may be broken I haven't enabled it.) This patc= h > adds the complementary -z dynamic-undefined-weak, extends both option= s > to affect building of shared libraries as well as executables, and > adds support for the option on powerpc. > Another undefined weak symbol linker bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D22269 --=20 H.J.