Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 8 Jan 2019 23:10:06 +0100
From: Markus Wichmann <>
Subject: Re: pthread_key_create bug?

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?

And if a port had to fudge things to get weak aliases to work, they
could just continue to fudge things to make weak references into strong
ones. This is merely an optimization; not having the weak reference
doesn't break anything, just increases the binary size.

> 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.
> Rich

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.

Not saying this is that situation, of course.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.