search

theRockLiu / thread-sanitizer

Automatically exported from code.google.com/p/thread-sanitizer
0 stars 0 forks source link

Link with instrumented libc++ if possible #62

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
LLVM r208737 added the build rules for tsan-instrumented libcxx 
(libcxx.llvm.org). For now we use it only to run a few lit tests (e.g. tests 
that verify that TSan sees synchronization used in std::shared_ptr 
implementation). However, we may go further and:
1) build TSan-instrumented libcxx in a normal build process
2) install it together with TSan runtime (in Clang resource directory, or 
somewhere else).
3) link user C++ programs against it, if user specifies -fsanitize=thread (and, 
probably, -stdlib=libc++).

Original issue reported on code.google.com by samso...@google.com on 14 May 2014 at 11:40

GoogleCodeExporter commented 9 years ago 
Doing this for MSan would be amazing, and even more important than for TSan.

But how do you plan to link with a shared library that's part of the toolchain? 
It might not be there when the program is run. Sounds like we must decide on a 
standard location for sanitizer-instrumented libraries (sysroot-relative, smth 
like /usr/lib/*san/), and add rpath to that location in the driver.

Original comment by euge...@google.com on 15 May 2014 at 7:35

GoogleCodeExporter commented 9 years ago 
Storing the xsan-instrumented libraries next to the runtimes (in the Clang 
resource directory) is convenient. When I install Clang to my local machine, 
the default path to resource dir is:
  /usr/local/lib/clang/3.5.0/lib/linux/
Suppose we store the xsan-instrumented libc++ as:
  /usr/local/lib/clang/3.5.0/lib/linux/xsan/libc++.so
and Clang driver on "-stdlib=libc++ -fsanitize=thread" passes the following 
opts to the linker:
  "-lc++" "-rpath=/usr/local/lib/clang/3.5.0/lib/linux/xsan/"

Will the executable pick up the instrumented version of runtime, and fallback 
to any other libc++.so he can find if rpath is unavailable?

Original comment by samso...@google.com on 16 May 2014 at 1:00

GoogleCodeExporter commented 9 years ago 
I think it would work, but hardcoding toolchain paths in the binary does not 
feel right. It would break in any cross-compilation setting.

libc+ belongs in sysroot. Clang driver already has lots of knowledge about 
sysroot layout in all common OSes and distributions. We should standardize on a 
sysroot-relative location for sanitizer instrumented libraries and install 
libc++-msan there.

Original comment by euge...@google.com on 19 May 2014 at 8:10