<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 6, 2017, at 4:08 PM, Michael Clark via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Folks,</div><div class=""><br class=""></div><div class="">I’m working on a port of musl libc to macos (arch triple is “x86_64-xnu-musl”) to solve some irreconcilable issues I’m having with libSystem.dylib. I don’t want to use glibc for various reasons, mainly because I want to static link. I have static PIE + ASLR working which is not actually supported by the Apple toolchain (*1), but I managed to get it to work. I’m sure Apple might say “Don’t do that”, but from looking at the history of the xnu kernel ABI, it seems to be very stable between versions.</div></div></div></blockquote><div><br class=""></div>I am from Apple, and I will say “Don’t do that.” The kernel ABI for our platforms is not stable, we only guarantee stability at the dynamic link boundary (in this case public symbols exported from libSystem). While the kernel syscall numbers have not changed (though the kernel team reserves the right to do that), the parameter lists and argument marshaling for them certainly has changed. We also do not support static executables on our system.</div><div><br class=""></div><div>We even had bincompat issues related to this i rolled their during the last major release (macOS 10.12 Sierra): Go implemented its own syscall support, which caused all of their binaries that used gettimeofday since the internal interface changed <<a href="https://github.com/golang/go/issues/16606" class="">https://github.com/golang/go/issues/16606</a>>. More broadly you can look at a discussion of their issues here: <<a href="https://github.com/golang/go/issues/16606" class="">https://github.com/golang/go/issues/16606</a>>. In their case they want to avoid invoking an external linker like ld64 or lld as opposed to avoiding libSystem, but the effect is the same, they shipped a tool that caused unsuspecting developers to have surprise bincompat issues that were entirely avoidable.</div><div><br class=""></div><div>Ultimately if you are doing this on your own for your own for fun thats great, but if this something you intend to ship to other people please reconsider. It is more than a theoretical concern that it will break.</div><div><br class=""></div><div>Louis</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">In any case the musl libc source makes extensive use of weak aliases, perhaps to allow easier interposition of C library routines, however aliases, weak or otherwise are not currently supported by ld64.</div><div class=""><br class=""></div><div class="">It appears that the mach-o format supports aliases, but the functionality has not been exposed via the linker (ld64/LLD).</div><div class=""><br class=""></div><div class="">- <a href="http://blog.omega-prime.co.uk/?p=121" class="">http://blog.omega-prime.co.uk/?p=121</a></div><div class=""><br class=""></div><div class="">The musl code does the following which currently errors out saying aliases are not currently supported:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">#undef weak_alias</div><div class="">#define weak_alias(old, new) \</div><div class=""> extern __typeof(old) new __attribute__((weak, alias(#old)))</div></blockquote><div class=""><br class=""></div><div class="">and the macro is used internally like this:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">int __pthread_join(pthread_t t, void **res)</div><div class="">{</div><div class=""> // implementation here</div><div class="">}</div><div class=""><br class=""></div><div class="">weak_alias(__pthread_join, pthread_join);</div></blockquote><div class=""><br class=""></div><div class="">The problem is the actual export used by clients is an alias and I want to maintain source compatibility.</div><div class=""><br class=""></div><div class="">I seem to have found a way to semi-emulate aliases (at least within one module). My goal is to at least turn them into strong aliases somehow, so I can at a minimum make the musl source compatible with clang on macos. The following compiles but foo is not exported:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">$ cat a.c</div><div class="">#include <stdio.h></div><div class=""><br class=""></div><div class="">void foo() __attribute__((weak_import)) __asm("_bar");</div><div class=""><br class=""></div><div class="">void bar()</div><div class="">{</div><div class=""> printf("bar\n");</div><div class="">}</div><div class=""><br class=""></div><div class="">int main()</div><div class="">{</div><div class=""> foo();</div><div class="">}</div><div class=""><br class=""></div><div class="">$ cc -c a.c -o a.o<br class="">$ nm a.o<br class="">0000000000000000 T _bar<br class="">0000000000000020 T _main<br class=""> U _printf</div></blockquote><div class=""><br class=""></div><div class="">Any ideas how I can get foo as an exported symbol? </div><div class=""><br class=""></div><div class="">Is weak alias or plan alias support planned for mach-o in LLD?</div><div class=""><br class=""></div><div class="">The goal at a minimum is to make the weak_alias macro emit a strong alias with clang/ld64 or clang/LLD? so I don’t need to diverge too much from the upstream musl source (as the lack of alias support currently requires me to rename function declarations in the source). Of course pthreads which I’m working on now are going to be completely different… but musl has support for architecture specific overrides in its build system.</div><div class=""><br class=""></div><div class="">BTW I now have some quite non-trivial programs compiling against musl-xnu + libcxx + libcxxabi on macos.</div><div class=""><br class=""></div><div class="">There are a lot of libcxx changes like this:</div><div class=""><br class=""></div><div class="">-#ifdef __APPLE__<br class="">+#if defined(__APPLE__) && !defined(_LIBCPP_HAS_MUSL_LIBC)<br class=""><br class=""></div><div class="">Michael.</div><div class=""><br class=""></div><div class="">[1] <a href="https://gist.github.com/michaeljclark/0a805652ec4be987a782afb902f06a99" class="">https://gist.github.com/michaeljclark/0a805652ec4be987a782afb902f06a99</a></div></div>_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>