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.8 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=unavailable 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 A2A231F5AE for ; Wed, 28 Apr 2021 07:44:20 +0000 (UTC) Received: from localhost ([::1]:47364 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lberr-0005EE-Eh for normalperson@yhbt.net; Wed, 28 Apr 2021 03:44:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47796) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lbern-0005Cf-P7 for bug-gnulib@gnu.org; Wed, 28 Apr 2021 03:44:16 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:43410) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lberk-0005VM-Q0 for bug-gnulib@gnu.org; Wed, 28 Apr 2021 03:44:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619595850; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=t1qWTimhx6eLXVuyJRCxx+m1tIEXHFMFgmnWfNPyT1c=; b=ZWxNI71FS/1rlMpmm0nXD6ZzqIlFxv+DOK+wVj0TKPrPsIaKRxzrLkoO18kMbTNApiOQXd 6HoAgwYGAMgVpvfs3svAiwEXhYnlT9LXoRfaoGYkfuOufYUpmB518YuW6oF8cE+BCsiwXh BrY+DUBsZnK9qD8ZKBTqtWs/zamSDG4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-366-uQqKgOxwOryufAWgk5Pnbg-1; Wed, 28 Apr 2021 03:44:05 -0400 X-MC-Unique: uQqKgOxwOryufAWgk5Pnbg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AAA1D107AD28; Wed, 28 Apr 2021 07:44:03 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-113-20.ams2.redhat.com [10.36.113.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DAEAA6BC0C; Wed, 28 Apr 2021 07:44:01 +0000 (UTC) From: Florian Weimer To: Bruno Haible Subject: Re: Undefined use of weak symbols in gnulib References: <87o8e0p92r.fsf@oldenburg.str.redhat.com> <87fszc8a1z.fsf@igel.home> <87eeewnfzw.fsf@oldenburg.str.redhat.com> <1680226.UWtE2gOZdF@omega> Date: Wed, 28 Apr 2021 09:44:31 +0200 In-Reply-To: <1680226.UWtE2gOZdF@omega> (Bruno Haible's message of "Wed, 28 Apr 2021 02:09:19 +0200") Message-ID: <87a6piluow.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=fweimer@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=170.10.133.124; envelope-from=fweimer@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.218, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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: Andreas Schwab , libc-alpha@sourceware.org, bug-gnulib@gnu.org, binutils@sourceware.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" * Bruno Haible: > 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 b= inutils 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, I could have used the weak pragma just like gnulib. > - why f2 is declared weak, Oh, sorry for the confusion, it's a quick way to establish a full compiler barrier with GCC. > - why the program skips its initializations in single-threaded mode, It's a minimal test. > - 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]? The relevant scenario here is LD_PRELOAD of a library that depends on libpthread.so.0, so it's about indirect preloading of something that's more usefull than just libpthread.so.0. pthread_key_create would still become available in this case. > > 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? If recompiled in this way: The presence of -lpthread will not matter, it will always behave is if linked with -lpthread. If not recompiled and linked without -lpthread against glibc 2.33 or earlier, the behavior with the current glibc 2.34 snapshot is architecture-dependent and also depends on the binutils version used for linking the program. In some cases, calling pthread_once jumps to address zero (causing a crash), or the call to pthread_once is elided from the executable. This scenario can be emulated with older glibc using LD_PRELOAD=3Dlibpthread.so.0. I will try to come up with a way to preserve the glibc 2.33 behavior for old binaries. However, you should really remove those weak symbol hacks. They won't have any effect for glibc 2.34, and as explained, they cause breakage with earlier glibc versions with certain LD_PRELOAD-ed libraries. Thanks, Florian