Date: Thu, 5 Sep 2019 14:18:46 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: About those weak aliases On Thu, Sep 05, 2019 at 07:29:04PM +0200, Markus Wichmann wrote: > On Thu, Sep 05, 2019 at 06:58:22PM +0200, Szabolcs Nagy wrote: > > can you show an example use of open in musl code > > where it is called form an api implementation > > that is defined by iso c? > > > > No, I can't. And I think I understand now. > > musl is trying to prevent linker errors from namespace pollution. More > specifically, to prevent double definition errors. Such an error would > happen during static linking, if a strong symbol from an unrelated > standard were pulled in. To that end, weak aliases are handed out on an > as-needed basis. open() is not needed to implement any interface from a > standard it is not a part of (fopen() inlines the syscall), so it gets > no alias. mmap() is needed to implement malloc(), so it gets one. Repeat > for all other functions. > > How close am I? Correct, but not complete. It's also a matter of preventing not diagnosable linker errors, but calling the *wrong function*, in the case of both static and dynamic linking. If for example fopen called open but the application defined open, that would not be a linker error. For static linking, the file defining open from libc.a (open.o) simply wouldn't get pulled into the link since there would be no outstanding unresolved reference to open another .o file already defined it. For dynamic linking, semantically the same thing would happen -- ELF semantics duplicate static linking semantics, requiring that functions from shared libraries be interposable. Now, musl uses --dynamic-list (previously -Bsymbolic-functions) which binds these symbols at libc.so link-time, but that's just an optimization, relying on the fact that redefining them would be UB so we can assume it doesn't happen. It's not required and won't be done if configure determines that the tooling doesn't support it. The case where a link error would come up is rarer, and happens when the reserved symbol is defined in the same file or pulled in by something else. For example, if you use mtx_lock, that will pull in __pthread_mutex_timedlock. If pthread_mutex_timedlock were also defined in the same file and were not weak, this could be a duplicate definition error at link time when the main program defines its own pthread_mutex_timedlock. One example where they appear in the same file is pthread_join with the pthread_*join_np functions in the same file -- if they were strong definitions rather than just weak aliases that would produce link errors on certain valid usage. 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.