Date: Tue, 8 Jan 2019 19:29:53 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: pthread_key_create bug? 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
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.