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

[Marcos Pividori via Phabricator via llvm-commits]

mpividori added a comment.

> This is all about code duplication, right? When you use static libraries - linking gives you an error. When you use dynamic libraries the code is still duplicated, right? Each .so file will still have its own copy of common functions and data. But loader will just pick the first version.

I see we only use shared libraries for APPLE, I was wondering why can't we use static libraries there? (for asan, we also provide shared libs for linux).
When using shared library the code of san_common is duplicated. The global data and the static constructors are duplicated.
When resolving the undefined references to sanitizer_common's functions on the main executable, I understand the linker will pick the first shared library that defines that symbols and link with that.

I think we could have problems using shared libraries, and including san_common code twice, that maybe we didn't realize before.
I mean, I will explain this with an example, 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`.
So, san_common's code will be included in both: `asan.so` and` ubsan.so`.
The references to san_common in `main.o` (the instrumentation) will be linked to the implementation in `asan.so`, since it is the first to be considered.
But the implementation of `ubsan.so` will be considering its own implementation (not the one included in `asan.so`).
So, I think we could have problems because the code and data from san_common is duplicated and it is not the same considered by `asan` and `ubsan`.
I think we could fix this problem, ALWAYS including san_common as a static library in the main executable, and not including that code in the shared libraries nor the static library.
This way, we can be sure that the code of san_common is not duplicated in the final program.


Repository:
  rL LLVM

https://reviews.llvm.org/D28359