I ran into an issue where it looks like the libc++abi demangler isn’t being used at all by sanitizer runtimes despite libc++abi being statically linked against. That is, if I were to make an executable that statically linked against libc++abi.a (which has a strong definition for
__cxa_demangle) and libclang_rt.tsan.a (which has a weak reference to
__cxa_demangle), then my final executable will contain an undefined weak
__cxa_demangle symbol. This happens because the tsan runtime has no strong reference to
__cxa_demangle, and thus will not link in libc++abi.a(cxx_demangle.cpp.o), the object file containing the actual definition for __cxa_demangle.
I hit this while running compiler-rt tests and found that some tests which require libc++abi (and actually link against libc++abi.a) do not actually symbolize correctly and thus fail. We could work around this in tests by adding
-u __cxa_demangle to compiler-rt tests, but that seems like an undesirable workaround that’s only limited to tests, and would differ from how users actually use sanitizers (unless it was added to the driver given some sanitizer flags, but I’m not sure if we’d want that).
My question is: what are ways libc++abi can correctly be statically linked in with sanitizer runtimes (that is, get __cxa_demangle to properly manifest)? I’m assuming that it was intentional for (1) __cxa_demangle to be weakly referenced because sanitizers should still be able to work without libc++abi, and (2) libc++abi.a is meant to be statically linked in with sanitizer runtimes so, if it was used, then it would only link parts of libc++abi and not the bulk of it.