bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Bruno Haible <bruno@clisp.org>
Cc: Florian Weimer <fweimer@redhat.com>,
	GNU C Library <libc-alpha@sourceware.org>,
	Andreas Schwab <schwab@linux-m68k.org>,
	bug-gnulib@gnu.org, Binutils <binutils@sourceware.org>
Subject: Re: Undefined use of weak symbols in gnulib
Date: Tue, 27 Apr 2021 19:10:56 -0700	[thread overview]
Message-ID: <CAMe9rOpK8DFL3EBgx1d29bppOZERe=-XiznJkDFJSSxczCRfbA@mail.gmail.com> (raw)
In-Reply-To: <1680226.UWtE2gOZdF@omega>

On Tue, Apr 27, 2021 at 6:57 PM Bruno Haible <bruno@clisp.org> wrote:
>
> Hi Florian,
>
> > Here's a fairly representative test case, I think.
> >
> > #include <pthread.h>
> > #include <stdio.h>
> >
> > 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 != NULL)
> >     pthread_once (&once_var, f1);
> > }
> >
> > int
> > main (void)
> > {
> >   f2 ();
> > }
> >
> > Building it with “gcc -O2 -fpie -pie” and linking with binutils 2.30
> > does not result in a crash with LD_PRELOAD=libpthread.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?
>
> =====================================================================
> #include <pthread.h>
> #include <stdio.h>
>
> #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 != NULL)
>     {
>       puts ("multi-threaded initialization");
>       pthread_once (&once_var, do_init);
>     }
>   else
>     do_init ();
> }
>
> int
> main (void)
> {
>   init ();
> }
> =====================================================================
>
> $ 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-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=19636
https://sourceware.org/bugzilla/show_bug.cgi?id=19704
https://sourceware.org/bugzilla/show_bug.cgi?id=19719

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 <amodra@gmail.com>
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.

-- 
H.J.


  reply	other threads:[~2021-04-28  2:11 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-27  5:53 Undefined use of weak symbols in gnulib Florian Weimer
2021-04-27  6:50 ` Paul Eggert
2021-04-27  6:58   ` Florian Weimer
2021-04-27  7:13     ` Paul Eggert
2021-04-27  7:24 ` Andreas Schwab
2021-04-27 11:06   ` Florian Weimer
2021-04-28  0:09     ` Bruno Haible
2021-04-28  2:10       ` H.J. Lu [this message]
2021-04-28  2:13         ` H.J. Lu
2021-05-05 20:31           ` Fangrui Song
2021-04-28  8:35         ` Florian Weimer
2021-04-28 13:15           ` Michael Matz
2021-04-28  7:44       ` Florian Weimer
2021-04-28 14:48         ` Bruno Haible
2021-04-28 17:44           ` Florian Weimer
2021-07-17 14:38         ` Bruno Haible
2021-07-17 14:55           ` Florian Weimer
2021-07-17 16:39             ` Bruno Haible
2021-07-27 20:02           ` Joseph Myers
2021-07-27 20:19             ` Florian Weimer
2021-07-27 23:38               ` Paul Eggert
2021-07-17 16:21         ` Bruno Haible
2021-04-27 23:22   ` Bruno Haible
2021-04-27 23:47 ` Bruno Haible
2021-04-28  7:57   ` Florian Weimer
2021-04-28 14:40     ` Bruno Haible
2021-04-28 17:43       ` Florian Weimer
2021-04-29 15:15         ` Bruno Haible
2021-04-30  9:55           ` Florian Weimer
2021-04-29  6:33       ` Ben Pfaff
2021-05-03  1:44 ` Alan Modra
2021-07-12 10:04 ` Michael Hudson-Doyle
2021-07-12 15:03   ` Florian Weimer
2021-07-12 15:30     ` Matthias Klose
2021-07-12 15:37       ` Florian Weimer
2021-07-13  0:22         ` Michael Hudson-Doyle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMe9rOpK8DFL3EBgx1d29bppOZERe=-XiznJkDFJSSxczCRfbA@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=schwab@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).