RFR (S): Supports statically linking TSAN runtime into the launcher with Clang

[Jean Christophe Beyler]

LGTM, I am curious about the clang write of size 1 issue but I suggest we
push that to post this submission; that way we all have the info to build
and test,
Jc

*From: *Man Cao <manc at google.com>
*Date: *Mon, May 13, 2019 at 10:15 PM
*To: * <tsan-dev at openjdk.java.net>

FYI, I used the pre-built LLVM 8.0.0 for Ubuntu 18.04 from here:
> http://releases.llvm.org/download.html#8.0.0
>
> I will also update the wiki page if everyone likes this workaround.
>
> -Man
>
>
> *From: *Man Cao <manc at google.com>
> *Date: *Mon, May 13, 2019 at 10:08 PM
> *To: * <tsan-dev at openjdk.java.net>
>
> Hi all,
> >
> > Can I have reviews for this patch that hopefully will unblock us from the
> > libtsan.so's version issue?
> > https://cr.openjdk.java.net/~manc/tsan20190513/webrev.00/
> >
> > This is a workaround for the version issue with libtsan.so in GCC. If we
> > build the JDK with Clang, we will have a newer version of the TSAN
> runtime
> > statically linked into the launcher:
> > $ nm images/jdk/bin/java | grep tsan_symbolize
> > 000000000048e640 W __tsan_symbolize_external
> > 000000000048e650 W __tsan_symbolize_external_ex
> >
> > In the long term, Java TSAN will still work with GCC, but stack trace
> > symbolization will be broken until OpenJDK can be built with GCC9, which
> > contains the new version of libtsan.so that we need.
> > Also need to write distinct values to the global variable in
> > libAbstractNativeLoop.cpp, otherwise some optimization in Clang could
> treat
> > the variable as constant, and TSAN reports "Write of size 1" instead of
> > "size 4".
> >
> > I have tested this with both LLVM 8.0.0 and GCC.
> >
> > -Man
> >
>


-- 

Thanks,
Jc