[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 8 Jan 2019 23:10:06 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
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.
Ciao,
Markus
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.
