Driver interaction with -fsanitize=memory

The memory sanitizer requires that the entire program (minus libc) be
built with it. When building a program that uses external libraries,
that means building them first and passing -L so that they are found.
For regular libraries I think this is fine, as it is no different from
having newer versions of libraries installed somewhere in $HOME for
example.

For the c++ library the situation is a bit different. The driver
normally handles it, so using a libc++ built with msan currently
requires something like "-nostdinc++ -I$INST/include/ -L$INST/lib
-lc++".

Adding a --libc-prefix option (similar to --gcc-toolchain) would help,
but we would still need to use

* clang -fsanitize=memory -stdlib=libc++ --libc-prefix=prefix1
* clang -fsanitize=memory -fsanitize-memory-track-origins
-stdlib=libc++ --libc-prefix=prefix2

Maybe a better option is

* Support libc++ installed alongside clang, as we do with libstdc++
* Look for the library with a suffix. That would allow multiple
versions installed together:
  * clang++ -fsanitize=memory: look for libstdc++-msan.so
  * clang++ -fsanitize=memory -stdlib=libc++: look for libc++-msan.so
  * clang++ -fsanitize=memory -stdlib=libc++
-fsanitize-memory-track-origins: look for libc++-msan-track.so

Any preferences?

Cheers,
Rafael

Another option we've been using is placing libc++/libstdc++ at a
standard library path + a suffix, like /usr/lib/msan. Driver could add
an -L for that path before /usr/lib. Other msan-instrumented system
libraries could be placed at that path, too, and they will be
automagically picked up when building with msan.

I like the idea of installing libc++ alongside clang. Could we have
that as default (with either -msan name suffix, or /msan/ path suffix,
not sure which is better), but overrideable with something like
--libc++-path?

I like the idea. I will try to first make clang look for libc++ in the
install dir and then implement the lib/msan logic.

Cheers,
Rafael

Hi,

Is there an intention to extend this to the more general case where cross-compiling requires access to target libraries for (whichever) cross-targets are available?

(or is there some other accepted scheme analogous to sysroots ?)

I guess something similar could be done. The main difference is
probably that we have more flexibility in defining an expected layout
for msan. With cross compilation one normally wants clang to use an
existing toolchain layout.

Cheers,
Rafael

Hi,

Please also include tsan into this plan (and probably asan?). Tsan does not
need to see all memory accesses, but it needs to see all synchronization.
Some atomic-operation-based synchronization in shared_ptr is compiled into
libstdc++ and causes false positives:
http://llvm.org/bugs/show_bug.cgi?id=17066

Hi,

Please also include tsan into this plan (and probably asan?). Tsan does not
need to see all memory accesses, but it needs to see all synchronization.
Some atomic-operation-based synchronization in shared_ptr is compiled into
libstdc++ and causes false positives:
http://llvm.org/bugs/show_bug.cgi?id=17066

If we are going to implement this for msan and asan, surely we want this
for asan as well. It will improve asan in two ways:
1. memory accesses in libraries will now be instrumented (and thus more
bugs will be detected).
2. the libraries will get compiled with frame pointers thus allowing fast
unwinder to work properly (this is essential for suppressions in lsan).

--kcc