Re: pthread_key_create bug?

[Rich Felker <dalias@libc.org>]

On Tue, Jan 08, 2019 at 11:10:06PM +0100, Markus Wichmann wrote:
> On Mon, Jan 07, 2019 at 07:00:18PM -0500, Rich Felker wrote:
> > I think you're right, though we don't generally use weak references in
> > musl on the basis (perhaps somewhat dubious) that they're an
> > additional toolchain feature that might cause problems reusing the
> > code in non-ELF contexts (this may affect midipix; I'm not sure).
> > That's why weak aliases to dummy functions are used for this purpose
> > everywhere else.
> > 
> 
> I don't quite get you. Weak aliases are just weak references with a
> non-zero default value. Any toolchain being able to handle weak aliases
> should be able to handle weak references, right?

No, not necessarily, and no they're not equivalent to weak definitions
with a zero value. A weak definition with a zero value would provide a
definition for other translation units to see/use, preventing one
with a non-weak reference from pulling in the real definition. Weak
references are a property of the reference. Weak definitions are a
property of the definition. They are not in any way equivalent.

In any case, the policy is that we don't use weak references (*). If
there were a strong reason to want them, we could review the reasons
and see if they are still relevant.

(*) This is only partly true. There are weak references to some
special ELF symbols defined by the linker, because providing a weak
definition would override the linker-provided value. For these, there
will never be definitions provided by source files, so the weak
reference is mostly equivalent to a weak definition by your above
logic. Furthermore, we know they'll always be defined for
position-independent linking (_DYNAMIC has to exist for shared
libraries and PIE) so there is no concern about the issue below
(PC-relative references to an undefined weakly-referenced symbol).

> > Also: weak references to hidden functions historically had some
> > breakage with respect to generating unresolvable-at-ld-time
> > pc-relative references to the symbol. Thus their use might break some
> > gcc/binutils versions too.
> 
> OK, that's interesting. But do we really want to work around bugs in
> gcc/binutils? Especially ones that were fixed a while ago? Because that
> might lead us to a situation where we have ugly code we can't improve
> because an old version of binutils had a bug, which is a fact that will
> never go away, so the code stays ugly forever.

It depends on the situation. In this case the functionality itself is
an extension to the language and it's not formally defined exactly
what usage is valid; we have to infer that from what the tools do and
how they're documented. The whole point here is to minimize the extent
to which we depend on behavior that has historically differed between
tools, so that we don't get bogged down worrying about the specifics
of it.

Rich