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

[Jean Christophe Beyler]

Well we do care about correctness and there was no reason for TSAN to
provide a "wrong" size. In this case, it is an optimization of clang that
provokes this 1 vs 4 byte difference.

Basically clang is able to ascertain a single value is being written into
the global variable and transform it into a boolean, "if you wrote it in,
I'll return the value you wanted to write in it"
Jc

*From: *Arthur Eubanks <aeubanks at google.com>
*Date: *Tue, May 14, 2019 at 10:50 AM
*To: *Jean Christophe Beyler
*Cc: *Man Cao, <tsan-dev at openjdk.java.net>

This looks promising, let me do some testing.
>
> Regarding the size of the write in native code, we should probably not
> depend on the exact size, since that's not what we care about.
>
> *From: *Jean Christophe Beyler <jcbeyler at google.com>
> *Date: *Tue, May 14, 2019 at 10:31 AM
> *To: *Man Cao
> *Cc: * <tsan-dev at openjdk.java.net>
>
> 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
>>
>

-- 

Thanks,
Jc