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=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, 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 B7B601F5AE for ; Wed, 28 Apr 2021 02:11:36 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B5A4039B680E; Wed, 28 Apr 2021 02:11:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B5A4039B680E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619575895; bh=wfFB9Pqx2CKjJY2qKtKhCcFSEXwvg+lpOzO5M3BYg54=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=cNoYgBclYIlDKe1hTcQqP0kPICflSqk5h7zBrSSa0yDnufMHucxKSxr8wPqiu8il5 s7c+DITdeQgi+NWESQk6cRMnKdVMs/bPDcwJTf0KjGoKzeW6Rbg50cwfQePj0kPiMr QlKrCtF4o6rliVCi1sc3XoxQQ66ezfHikN366nw4= Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) by sourceware.org (Postfix) with ESMTPS id 30403385781C; Wed, 28 Apr 2021 02:11:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 30403385781C Received: by mail-oi1-x22d.google.com with SMTP id z7so9394049oix.9; Tue, 27 Apr 2021 19:11:33 -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=wfFB9Pqx2CKjJY2qKtKhCcFSEXwvg+lpOzO5M3BYg54=; b=uI5sRORBhsULbtNWq5L8A4op/v4lkxOZ7Q+yhib7fiSnFWoS+HRces5mqxARt79A0D W9L75loTn6ILKdJJE5MqPiF8WDEegZ/uAnJIZz9uQPcbxtuoLqaFs0wFnLCFqEhJbBVi a1D0mxnkcBWOvfZjafrZPcdGak4Q62HaHfV7LlS5WiDY8BwryeMuRk0XKCDyuiLM41VL 1aoiSLUTf+CprUvqJaQ5f6Lb0L72NvIVxhqVXQpyKctXQytBMQpdvIgsa/I8pFnuIM1F cMjXTGy5dIWjKXMlFNrodcj52j7td/X2g9Us1KrcyAtA1LYlpCs3CB//N3ad8Z3yRxLj PLZg== X-Gm-Message-State: AOAM532r3CEin2GpJowR1hTkSUbm9ilV+TgHC2zDtH6uGJZZ87l0ovD/ GEJ85nEqWRHA4o2ueV6NZoaVZultdrtNzSPy04k= X-Google-Smtp-Source: ABdhPJygjdhIIJBjS0t+ym/sUbLDJzdsll1uH6MEI9am784tklT7zJ0YB0W5jcQJzsBepq9eN3vufQS5FZt7V4sCRpU= X-Received: by 2002:a05:6808:2d0:: with SMTP id a16mr9937900oid.116.1619575892526; Tue, 27 Apr 2021 19:11:32 -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: <1680226.UWtE2gOZdF@omega> Date: Tue, 27 Apr 2021 19:10:56 -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 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: , From: "H.J. Lu via Libc-alpha" Reply-To: "H.J. Lu" Cc: Florian Weimer , GNU C Library , Andreas Schwab , bug-gnulib@gnu.org, Binutils Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" 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 with = 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 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 > 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-i= mplemented-by-weak-symbol-to-provide-pthread-stub-functi/21103255 > [4] https://stackoverflow.com/questions/20658809/dynamic-loading-and-weak= -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 patch adds the complementary -z dynamic-undefined-weak, extends both options to affect building of shared libraries as well as executables, and adds support for the option on powerpc. --=20 H.J.