[PATCH] D42390: msan: Pass --disable-new-dtags for tests

[Jonas Hahnfeld via Phabricator via llvm-commits]

Hahnfeld added a comment.

In https://reviews.llvm.org/D42390#987008, @hintonda wrote:

> In https://reviews.llvm.org/D42390#986961, @Hahnfeld wrote:
>
> > I was half-way through implementing this and wanted to align `tsan` where we might have the same problem (for some reasons unknown to me the tests don't fail there?). However, setting environment variables like `LD_LIBRARY_PATH` in lit means that also the compiler will run in this environment:
> >
> >   symbol lookup error: <...>/projects/compiler-rt/lib/tsan/libcxx_tsan_x86_64/lib/libc++.so.1: undefined symbol: __tsan_init
> >
> >
> > This obviously works for tsan-binaries but not if some toolchain binaries are linked against `libc++`.
>
>
> I normally build on my mac, and haven't actually seen these errors.  Can you tell me how to reproduce?  Should I build/test on Linux?


This deserves some longer explanation and it was getting a bit late yesterday: The error only comes up with some local changes implementing the approach with `LD_LIBRARY_PATH`.

The "problem" is that I'm building with `LLVM_ENABLE_LIBCXX`, so `bin/clang` is linked against `libc++`. Additionally the "host" `clang` (that I'm using to build LLVM) was built the same way, so there already is a `libc++.so` in `LD_LIBRARY_PATH`. If some tests are linked with `-Wl,-rpath` and use `DT_RUNPATH`, the library in `LD_LIBRARY_PATH` takes precedence and the instrumented one is not used. If we however add the instrumented `libc++` to `LD_LIBRARAY_PATH`, `bin/clang` will also use it which results in the `symbol error` mentioned above when building tsan tests.

In https://reviews.llvm.org/D42390#987107, @hintonda wrote:

> No worries.  Like Jonas said, it's an ordering problem, so if you could prepend the correct paths to LD_LIBRARY_PATH, it should work -- perhaps easier said than done.
>
> Again, I think this could be done on a test by test basis which lit should be able to handle.


Yep, but as explained above we have the ordering issue both when compiling (where we don't want to have the instrumented `libc++`) and when executing the test (that's where we want the instrumented version!). That's why I wanted to use the "old" `DT_RPATH` which is evaluated before looking at `LD_LIBRARY_PATH` and is only set for the compiled test, not for `bin/clang`. If you are strongly against that, the only other possibility I see is setting `LD_LIBRARY_PATH` when executing the test, ie add a substitution like `%load_instrumented_libcxx` which evaluates to `env LD_LIBRARY_PATH=...`. This would avoid the problems when `bin/clang` also uses `libc++`.


Repository:
  rCRT Compiler Runtime

https://reviews.llvm.org/D42390