[llvm-dev] LLD support for mach-o aliases (weak or otherwise)
Michael Clark via llvm-dev
llvm-dev at lists.llvm.org
Tue Jun 6 16:08:42 PDT 2017
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.
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.
It appears that the mach-o format supports aliases, but the functionality has not been exposed via the linker (ld64/LLD).
- http://blog.omega-prime.co.uk/?p=121 <http://blog.omega-prime.co.uk/?p=121>
The musl code does the following which currently errors out saying aliases are not currently supported:
#define weak_alias(old, new) \
extern __typeof(old) new __attribute__((weak, alias(#old)))
and the macro is used internally like this:
int __pthread_join(pthread_t t, void **res)
// implementation here
The problem is the actual export used by clients is an alias and I want to maintain source compatibility.
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:
$ cat a.c
void foo() __attribute__((weak_import)) __asm("_bar");
$ cc -c a.c -o a.o
$ nm a.o
0000000000000000 T _bar
0000000000000020 T _main
Any ideas how I can get foo as an exported symbol?
Is weak alias or plan alias support planned for mach-o in LLD?
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.
BTW I now have some quite non-trivial programs compiling against musl-xnu + libcxx + libcxxabi on macos.
There are a lot of libcxx changes like this:
+#if defined(__APPLE__) && !defined(_LIBCPP_HAS_MUSL_LIBC)
 https://gist.github.com/michaeljclark/0a805652ec4be987a782afb902f06a99 <https://gist.github.com/michaeljclark/0a805652ec4be987a782afb902f06a99>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev