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 52447384B821; Wed, 28 Apr 2021 02:14:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 52447384B821 Received: by mail-ot1-x330.google.com with SMTP id n32-20020a9d1ea30000b02902a53d6ad4bdso2125181otn.3; Tue, 27 Apr 2021 19:14:04 -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:content-transfer-encoding; bh=T36/trJjuKaAdXoMbGW7w1rKLTeYzzZDAtsY5AfDh0M=; b=C9HecvygVVioDddHPUDexhowfNIfPM9PhRXV0WKvyDTqmbX+SeZKqLRm3SSlQbuijv /SQab8AnH7fvltOtjbbO2dD7MwKjDxQA9ZWrr1CJcu5uUmTZdBB5ZFxdCRRYTl80kFaR o+nNZBXh0XZE2Wo3I7AcJVEXk7Lb6GARMU7Sj8XaDvZ8V5aQ33Lx6vLP3HwZs7iYPfQg R6Xzy/M3i5zlLLZEj1RYFgPjV9SwMUZUohXvpYeK7Wqn1N1N/WA2nmC6jWNw/buw07rs 1y1fYLG9pDT9bkGGlnBALwD6KoKusqRmgQ0ZNzeSf7Rtfljv4LL828bkgdCdZdLwT06J KPdQ== X-Gm-Message-State: AOAM532WCOEJw1+kqa0ZtM+xevpOCn8QOhwqC/pX+E849lu34u7OfeT4 t7+etYIhyavt2qL3YCGwWbgP+MOwzqhyBPZbvWM= 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 Cc: bug-gnulib@gnu.org, Florian Weimer , GNU C Library , Andreas Schwab , Binutils Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3028.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 02:14:05 -0000 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.