[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Undefined use of weak symbols in gnulib
From: |
Florian Weimer |
Subject: |
Re: Undefined use of weak symbols in gnulib |
Date: |
Wed, 28 Apr 2021 09:57:08 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
* Bruno Haible:
> You write:
>> Dynamic linking with weak symbols is not very well-defined. ...
>> the code will crash if pthread_mutexattr_gettype is ever defined.
>
> In which situations will it crash?
>
> (a) when the code is in an executable, that gets linked with '-lpthread'
> and that does not use dlopen()?
The pthread_mutexattr_gettype is defined, but also pthread_once and the
weak symbols, so there is no problem because the link editor doesn't do
funny things.
> (b) when the code is in an executable, that gets linked WITHOUT
> '-lpthread' and that does not use dlopen()?
Yes, it will crash or behave incorrectly on most architectures *if*
pthread_mutexattr_gettype becomes available for some reason.
> (c) when the code is in an executable, that gets linked WITHOUT
> '-lpthread' and that does a dlopen("libpthread.so.X")?
This will probably work because pthread_mutexattr_gettype is not rebound
to the definition.
> Under which conditions will it crash?
>
> ($) when the executable was built before glibc 2.34 and is run
> with glibc 2.34 ?
Yes.
> (%) when the executable is built against glibc 2.34 and is run
> with glibc 2.34 ?
No. glibc 2.34 will behave as if an implicit -lpthread is present on
the linker program line.
> And if it crashes, will setting the environment variable LD_DYNAMIC_WEAK [1]
> avoid the crash?
No, it's unrelated. The crash or other undefined behavior is a
consequence of actions of the link editor and cannot be reverted at run
time. The best we can do is to hide definitions of symbols like
pthread_mutexattr_gettype, therefore masking the existence of those
corrupted code paths (like glibc 2.33 and earlier do).
Thanks for looking into this.
Thanks,
Florian
- Re: Undefined use of weak symbols in gnulib, (continued)
- Re: Undefined use of weak symbols in gnulib, Bruno Haible, 2021/04/27
- Re: Undefined use of weak symbols in gnulib, H.J. Lu, 2021/04/27
- Re: Undefined use of weak symbols in gnulib, H.J. Lu, 2021/04/27
- Re: Undefined use of weak symbols in gnulib, Florian Weimer, 2021/04/28
- Re: Undefined use of weak symbols in gnulib, Michael Matz, 2021/04/28
- Re: Undefined use of weak symbols in gnulib, Florian Weimer, 2021/04/28
- Re: Undefined use of weak symbols in gnulib, Bruno Haible, 2021/04/28
- Re: Undefined use of weak symbols in gnulib, Florian Weimer, 2021/04/28
Re: Undefined use of weak symbols in gnulib, Bruno Haible, 2021/04/27
Re: Undefined use of weak symbols in gnulib, Bruno Haible, 2021/04/27
- Re: Undefined use of weak symbols in gnulib,
Florian Weimer <=
Re: Undefined use of weak symbols in gnulib, Ben Pfaff, 2021/04/29