Re: About those weak aliases

[Rich Felker <dalias@libc.org>]

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