[PATCH] D28359: [compiler-rt] Use common static library for sanitizer_common.

[Marcos Pividori via Phabricator via llvm-commits]

mpividori added a comment.

In https://reviews.llvm.org/D28359#637481, @kubabrecka wrote:

> In https://reviews.llvm.org/D28359#637463, @mpividori wrote:
>
> > I see we only use shared libraries for APPLE, I was wondering why can't we use static libraries there?
> >  let suppose we compile `main.cc` with address and undefined behaviour sanitizers in APPLE.
> >  Then, clang will pass to the linker:  `main.o` ,  `asan.so` and `ubsan.so`.
>
>
> (On Darwin) When using both -fsanitize=address and -fsanitize=ubsan, the driver will only link in the ASan dylib.  It already __also__ contains the UBSan runtime.  This solution currently works and I don't see many problems with that because the number of sanitizer combinations is very limited (you can't use e.g. ASan with TSan together).
>
> We really want to keep using dynamic libraries (at least on Darwin), because 1) we're relying on features only available in dylibs (dyld interposition) and 2) you can easily link multiple instrumented modules (libraries) together without worrying which one should carry the static archive.


@kubabrecka

Thanks for your comments.

Ok, yes the code is included in asan shared library and clang only include the ubsan shared library when not required the asan shared library, I forgot to check clang driver.
Is there any reason to include ubsan and leak sanitizers in the asan shared library?
Don't you think it would be better to keep them separated so we can combine them only when necessary? this would also simplify clang driver code.

I see the `stats` shared library for apple also includes `sanitizer_common` 's code. So, when using "asan" and "stats" we are in the situation that I mentioned before, with duplicated code for sanitizer common.

I think the 2) reason you mention is not a problem, since clang will only include the static libraries when linking the executable, not when creating shared or static libraries.
So there is no problem in linking multiple instrumented modules, since none of them include sanitizer static libraries.


Repository:
  rL LLVM

https://reviews.llvm.org/D28359