Instead of putting the directory that contains libc++/libc++abi into LD_LIBRARY_PATH, use the system's 'normal' method of locating libraries, by ensuring that directory is included in the search path built up from /etc/ld.so.conf. If you do this, then an RPATH in an executable *will* take precedence over the default directory, because the default directory won't be specified in LD_LIBRARY_PATH (which has the highest precedence).
On Thu, Nov 26, 2015 at 4:09 AM, Schlottke-Lakemper, Michael via cfe-users < cfe-users@lists.llvm.org> wrote: > > On 25 Nov 2015, at 20:13 , Alexey Samsonov <vonos...@gmail.com> wrote: > > On Wed, Nov 25, 2015 at 4:12 AM, Schlottke-Lakemper, Michael < > m.schlottke-lakem...@aia.rwth-aachen.de> wrote: > >> >> Thus I tried to compile a complete LLVM/Clang stack (with compiler-rt, >>> libcxx, libcxxabi, libomp) using -DLLVM_USE_SANITIZER=MemoryWithOrigins. >>> However, this did not work either, as apparently during the compilation >>> process the memory sanitizer already comes to life and complains about >>> use-of-unitialized values… Thus this approach seems to be a dead end. >>> >>> Michael >>> >>> On 24 Nov 2015, at 15:28 , Michael Schlottke-Lakemper < >>> m.schlottke-lakem...@aia.rwth-aachen.de> wrote: >>> >>> Hi folks, >>> >>> When running our msan-instrumented simulation program, instead of a >>> proper output I get the following error: >>> >>> ==12089==WARNING: MemorySanitizer: use-of-uninitialized-value >>> ==12089==WARNING: Can't read from symbolizer at fd 14 >>> /pds/opt/llvm/bin/llvm-symbolizer: symbol lookup error: >>> /pds/opt/libcxx-20151121-r253770-clang-msan/lib/libc++abi.so.1: undefined >>> symbol: __msan_origin_tls >>> ==12089==WARNING: external symbolizer didn't start up correctly! >>> >>> My setup for using the memory sanitizer is as follows: >>> - compile libc++/libc++abi with -fsanitize=memory >>> - compile test program with normal (=uninstrumented) LLVM/Clang >>> installation using -fsanitize=memory >>> - put instrumented libcxx/libcxxabi library dirs into LD_LIBRARY_PATH >>> >>> Can you pass -Wl,-rpath when you link your executable, to specify the >> path to instrumented libc++/libc++abi? >> >> >> Yes, and if I do that together with setting LD_LIBRARY_PATH=“”, it works, >> thanks. >> > > Why do you need to clear LD_LIBRARY_PATH to run MSan? > What libraries from LLVM lib dir harm running the MSan-ified executalbe? I > thought that if you set rpath to correct path with instrumented libraries > it should be enough… > > > Right now I have the problem that by default, LD_LIBRARY_PATH includes a > directory with libc++/libc++abi in it. However, when running > msan-instrumented executables to test them, the executable should pick up > msan-instrumented versions of libc++/libc++abi while the subsequently used > llvm-symbolizer needs to pick up the uninstrumented versions (otherwise I > get the above-mentioned errors). Setting rpath is not enough, since the > presence of libc++/libc++abi in LD_LIBRARY_PATH will override it. Compiling > llvm-symbolizer in a way that it is able to run with msan-instrumented > libc++ might be an option, but I don’t know how to do that (other than > compiling all of LLVM with msan, which does not work either). > > One possible workaround that I have been using is to create a shell > script, call it “llvm-symbolizer”, put > > LD_LIBRARY_PATH="$LLVM_DIR/lib:$LD_LIBRARY_PATH" > $LLVM_DIR/bin/llvm-symbolizer $* > > in it, and make sure that it is on the PATH before the actual > llvm-symbolizer executable (which is located in LLVM_DIR/bin). However, > this is clearly a workaround and I am looking for a more robust and more > “canonical” solution. > > Any suggestions? > > Michael > > > _______________________________________________ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users > >
_______________________________________________ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
