<div dir="ltr">unsubscribe</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Cheers!<br>Vojtech<br><a href="http://www.meldaproduction.com" target="_blank">www.meldaproduction.com</a><div><a href="https://www.facebook.com/MeldaProduction" target="_blank">Facebook</a>, <a href="http://twitter.com/meldaproduction" target="_blank">Twitter</a>, <a href="http://www.youtube.com/user/meldaproduction" target="_blank">Youtube</a></div></div></div></div>
<br><div class="gmail_quote">2015-11-23 20:13 GMT+01:00 Schlottke-Lakemper, Michael via cfe-users <span dir="ltr"><<a href="mailto:cfe-users@lists.llvm.org" target="_blank">cfe-users@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On 23 Nov 2015, at 20:01 , Evgenii Stepanov <<a href="mailto:eugeni.stepanov@gmail.com">eugeni.stepanov@gmail.com</a>> wrote:<br>
><br>
> Yes. Effectively you need two environments - one with<br>
> msan-instrumented libraries, and one without. Compilation should<br>
> happen in the latter (unless you want to instrument the compiler which<br>
> is not very productive), and resulting binaries should be run in the<br>
> former.<br>
><br>
<br>
Ah, thanks a lot. Just to be sure: is it generally OK to compile & link in an environment where ld would e.g. pick up an uninstrumented version of the OpenMPI libraries as long as the correct, instrumented OpenMPI library is in LD_LIBRARY_PATH at runtime?<br>
<br>
Sorry for having to ask again<br>
<br>
Michael<br>
<br>
<br>
> On Mon, Nov 23, 2015 at 10:50 AM, Schlottke-Lakemper, Michael<br>
> <<a href="mailto:m.schlottke-lakemper@aia.rwth-aachen.de">m.schlottke-lakemper@aia.rwth-aachen.de</a>> wrote:<br>
>><br>
>>> On 23 Nov 2015, at 18:11 , Evgenii Stepanov <<a href="mailto:eugeni.stepanov@gmail.com">eugeni.stepanov@gmail.com</a>> wrote:<br>
>>><br>
>>> On Mon, Nov 23, 2015 at 12:59 AM, Schlottke-Lakemper, Michael via<br>
>>> cfe-users <<a href="mailto:cfe-users@lists.llvm.org">cfe-users@lists.llvm.org</a>> wrote:<br>
>>>> Hi folks,<br>
>>>><br>
>>>> I'm trying to set up our cluster tool chain to support clang’s memory<br>
>>>> sanitizer for our multiphysics simulation program, but I can’t get it to<br>
>>>> work :-/<br>
>>>><br>
>>>> I started with a regularly compiled clang installation (with libcxx,<br>
>>>> libcxxabi, and libomp built in-tree). With this, I compiled all necessary<br>
>>>> third-party libraries with “-O1 -fsanitize=memory” (OpenMPI, FFTW, Parallel<br>
>>>> netCDF). Then, I compiled the libcxx/libcxxabi libraries with msan-support<br>
>>>> by checking out the llvm source and the libcxx/libcxxabi repos into the<br>
>>>> llvm/projects/ directory. I configured them with LLVM_USE_SANITIZER=Memory<br>
>>>> and put the msan-instrumented libraries in the LD_LIBRARY_PATH.<br>
>>>><br>
>>>> Finally, I tried to compile our tool, ZFS, with the memory sanitizer enabled<br>
>>>> and linked against the msan-compiled third-party libraries as well as the<br>
>>>> msan-instrumented libcxx/libcxxabi libraries (by putting them in the<br>
>>>> LD_LIBRARY_PATH). However, here I failed: either at configure time or at<br>
>>>> compile time (after doing some LD_LIBRARY_PATH trickery), clang exits with<br>
>>>> the following error:<br>
>>>><br>
>>>> /pds/opt/llvm-20151121-r253770/bin/clang++: symbol lookup error:<br>
>>>> /pds/opt/libcxx-msan-20151121-r253770/lib/libc++abi.so.1: undefined symbol:<br>
>>>> __msan_va_arg_overflow_size_tls<br>
>>>><br>
>>>> Any suggestions as to what I am doing wrong? Should I put the<br>
>>>> msan-instrumented libcxx in the LD_LIBRARY_PATH after compilation only?<br>
>>><br>
>>> Yes, probably. In this case your compiler, which is not built with<br>
>>> MSan, picked up an instrumented libc++abi.<br>
>>> Sometimes it is convenient to set RPATH on all msan<br>
>>> libraries/executables and avoid LD_LIBRARY_PATH.<br>
>><br>
>> Thanks for your answer. Unfortunately, I cannot avoid LD_LIBRARY_PATH as it includes our cluster-wide LLVM lib dir by default on all our hosts. Thus setting RPATH at compile/link time will have no effect as there is no way to make it overrule LD_LIBRARY_PATH afaik. Instrumenting all of Clang with MSan seems a bit overkill to me (and does not solve the RPATH/LD_LIBRARY_PATH issue at runtime anyways). I guess I’ll just have to live with manually changing the LD_LIBRARY_PATH after compilation then.<br>
>><br>
>> Michael<br>
<br>
_______________________________________________<br>
cfe-users mailing list<br>
<a href="mailto:cfe-users@lists.llvm.org">cfe-users@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users</a><br>
</blockquote></div><br></div>