Hi llvm-dev,
I'm trying to reproduce an msan failure in one of the bots, but I
can't seem to get the right incantation of building LLVM with msan.
Here's what I've been doing:
1) Build the toolchain in one build directory, including `compiler-rt`.
2) Build the toolchain again with the just built toolchain in step 1,
but this time with `-DLLVM_USE_SANITIZER=MemoryWithOrigins`.
I get some msan errors, but of this kind instead of the one I'm expecting:
Hello Dean,
I've not done this myself for a while, I seem to remember it taking a
while to get right. When I did I found the page:
https://github.com/google/sanitizers/wiki/MemorySanitizerBootstrappingClang
useful. The other thing that might work is following the individual
cmake steps from
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan
. These aren't in the same structure as the monorepo but they may be
adaptable.
My apologies if you've tried these already.
Peter
Another option is just to run corresponding script from https://llvm.org/svn/llvm-project/zorg/trunk/zorg/buildbot/builders/sanitizers/ in empty directory.
Thanks Vitaly and Peter,
I went with a modified version of the instructions from MemorySanitizerBootstrappingClang · google/sanitizers Wiki · GitHub — that’s a very helpful set of instructions!
Cheers
Aside: would it be useful to execute a build of the libc++/libc++abi with msan normally during release, and change the driver to look for these msan-built C++ libs when “-fsanitize=memory”? That would drastically cut down on the complexity of using msan.
After recently setting up scripts and aliases locally to handle switching runtime builds based on which sanitizer I want to use, I second this. Is there any issue with the space required in the install? A Release build of the runtime with LLVM_USE_SANITIZER='Address;Undefined' appears to be 55MB on my machine. Is it reasonable to install a copy of the runtime for each sanitizer type?
Scott
This would be nice.
So, to be clear, there would be libc++.so / libc++.a somewhere under
lib/clang/.../$triple/msan, and the driver would link that if libc++
is not specified explicitly on the command line? Would it also add
-rpath? This could be weird because toolchain may not be present when
the binary is run.
We already do this for Fuchsia. We’ve added support for building sanitized runtimes (https://github.com/llvm-mirror/llvm/blob/master/runtimes/CMakeLists.txt#L501) and we use it to build ASan instrumented libc++/libc++abi/libunwind (https://github.com/llvm-mirror/clang/blob/master/cmake/caches/Fuchsia-stage2.cmake#L115) which end up in lib/clang/…/$triple/asan (if using the multiarch runtime layout which is the default for us). We hope to use other sanitizers in the future as well.
Since the instrumented and uninstrumented libc++/libc++abi/libunwind should have the same ABI, there should be no need to change which library you link against, the only thing that’s important is which library you load at runtime. On Fuchsia this is handled by our dynamic linker. On Linux we’ll likely need to use -rpath or some other solution.