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: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id D38891F5AE for ; Wed, 28 Apr 2021 00:09:31 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B8C91398EC1B; Wed, 28 Apr 2021 00:09:25 +0000 (GMT) Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [85.215.255.53]) by sourceware.org (Postfix) with ESMTPS id 21C3F385782B; Wed, 28 Apr 2021 00:09:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 21C3F385782B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=clisp.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=bruno@clisp.org ARC-Seal: i=1; a=rsa-sha256; t=1619568560; cv=none; d=strato.com; s=strato-dkim-0002; b=XS0luqQLpiBf1PUu9g6InmPfH8lO25V13KS1nwQCTg6cwuaAHpjTuhp9jBqE5Z66Zv lEKJGBmV9AvNil2lhsdp0LgLYUeEA0ZgCVtFikyqjVxBhxDVBOxTIt4Y/Kj/e2GHnj8U MeS8kgmiFnNCcZuVstBFHTo1FCBALZzp42bUFwvvsqRCDdEQTMD+kveeXQclQOiypDQO GLYA0zLWnSBq723GMAVHaI26Y9zUIDRzmcRKjAqBY1X6jg4S4NiHQa1Ca0/JnuwO+uvT NTQnIqIlc3E/y+R14NC/5Z7Z8kyXiWNAnLyESya7dmQCnCN0oOvA8wm+vXOwWtTc9qXT DWPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1619568560; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=v7VQDNYseUg+pbOAVa0+WJ2/FpoAMPeSFjY/fC8O8t4=; b=NoYCWjBtwWPNdCXYoC2FQINcUiBjMyUM9g78qdnFD0hO6r1vZhCDvRJSGjQ4+Ui+n7 Mzv5P9hr8q2ce34j3Rj5LyF0zu1LzFQ2dnEvC3wA2dN02DhXOK7K59Ng+US7ux3yEIlv 9pvWfiU9G1OTCPYOGaLFTzXMN72KwwP3U3D6DN2S0KT5Bvvr7MfQunDep5Y/vH6t/d3m AT+WRUt0IF0/FeqV2//27W/JH1G+1U/7aax/PhIu3xZjDtzufoxmI6uKsQYyHlNJsGRM NLYBGfhC1cJBLuLfhXvwvQb8G0pjutdDu+ARUJ8grQvhcO/Kp0EmRZBl/5IDc3xDQLEM X7Jg== ARC-Authentication-Results: i=1; strato.com; dkim=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1619568560; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=v7VQDNYseUg+pbOAVa0+WJ2/FpoAMPeSFjY/fC8O8t4=; b=R0bUkUjcbIXhQ8xXNBZdg1C8We9mI/9o1FVU8ozepsDUqIIB8Fkw0dkNZclh2uV+P7 1HGP6hQZ0O18QFb9UWu0eUN6ucCosR+ZKxslUrRrESFZBTjoxM1jz3u5qQkoBtSkhv2o rQJsk8hptszj/S5iddK21gSHt7yS6+qsPDdsFkhRovMDcXOLFr9SQXD11Ohasuh5y4YS 0m+2cfRVX2GW6jHZDdP6kBMWDk6qdBwu6miO9AYwGTFjuyWLQ7CgLS7obGMVFOb5+k1t mPa0rjYuJ9lS+axiH5UBUIPraVX0tK/+8pfbMCwQqxVgJf3GBcq1KwVotk4FW66b812q MNeg== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOHqf3z5NW" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 47.25.2 DYNA|AUTH) with ESMTPSA id 905ad3x3S09K3RA (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Wed, 28 Apr 2021 02:09:20 +0200 (CEST) From: Bruno Haible To: bug-gnulib@gnu.org Subject: Re: Undefined use of weak symbols in gnulib Date: Wed, 28 Apr 2021 02:09:19 +0200 Message-ID: <1680226.UWtE2gOZdF@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-206-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <87eeewnfzw.fsf@oldenburg.str.redhat.com> References: <87o8e0p92r.fsf@oldenburg.str.redhat.com> <87fszc8a1z.fsf@igel.home> <87eeewnfzw.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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: , Cc: Florian Weimer , libc-alpha@sourceware.org, Andreas Schwab , binutils@sourceware.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" Hi Florian, > Here's a fairly representative test case, I think. >=20 > #include > #include >=20 > extern __typeof (pthread_key_create) __pthread_key_create __attribute__ (= (weak)); > extern __typeof (pthread_once) pthread_once __attribute__ ((weak)); >=20 > void > f1 (void) > { > puts ("f1 called"); > } >=20 > pthread_once_t once_var; >=20 > void __attribute__ ((weak)) > f2 (void) > { > if (__pthread_key_create !=3D NULL) > pthread_once (&once_var, f1); > } >=20 > int > main (void) > { > f2 (); > } >=20 > Building it with =E2=80=9Cgcc -O2 -fpie -pie=E2=80=9D and linking with bi= nutils 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 POSIX 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=20 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-imp= lemented-by-weak-symbol-to-provide-pthread-stub-functi/21103255 [4] https://stackoverflow.com/questions/20658809/dynamic-loading-and-weak-s= ymbol-resolution