Right in the docs for the address sanitizer (https://releases.llvm.org/7.0.0/tools/clang/docs/AddressSanitizer.html), it states that:
When linking shared libraries, the AddressSanitizer run-time is not
linked, so -Wl,-z,defs may cause link errors
That appears to be true not only for ASAN, but UBSAN as well. This turns out to be particularly inconvenient with UBSAN, since the
vptr sanitizer can introduce new typeinfo dependencies between libraries (lots of details in https://jira.mongodb.org/browse/SERVER-49798).
I’d really prefer to build with
-Wl,-z,defs for our UBSAN builds. And I can actually make that work with a ubsan build so far as the compile goes, by manually injecting
-lubsan into the link lines for the shared libraries.
But that leaves me with a nagging question: why doesn’t the
clang link driver do this automatically when linking shared libraries, per the explicit documentation? It clearly could do it, since it already does it for programs which get the runtime automatically. The fact that it explicitly doesn’t leads me to wonder if doing so is somehow problematic.
- Is forcing the
ubsanruntime library onto the link line for all shared libraries a bad idea for some reason?
- Does it undermine the effectiveness of the sanitizer somehow?
- Is there some other horrible downside I’m not seeing?
Source: Windows Questions C++