[cfe-users] Clang memory sanitizer: llvm-symbolizer problem
Kevin P. Fleming via cfe-users
cfe-users at lists.llvm.org
Thu Nov 26 08:43:08 PST 2015
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 at lists.llvm.org> wrote:
> On 25 Nov 2015, at 20:13 , Alexey Samsonov <vonosmas at gmail.com> wrote:
> On Wed, Nov 25, 2015 at 4:12 AM, Schlottke-Lakemper, Michael <
> m.schlottke-lakemper at 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.
>>> On 24 Nov 2015, at 15:28 , Michael Schlottke-Lakemper <
>>> m.schlottke-lakemper at 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,
> 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
> $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?
> cfe-users mailing list
> cfe-users at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-users