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

[Man Cao]

Good to hear that it works. Thanks for the reviews!

-Man


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

I tested it with the patch that adds Java memory instrumentation and the
> stack traces look good (the package name is missing, but that's a different
> problem).
>
> One worry I have is that people who want to do this will have to build
> their native code with -Wl,--unresolved-symbols=ignore-in-object-files if
> they're using gcc, and also make sure not to link with -fsanitize=thread
> regardless of the compiler. Maybe for now that doesn't matter, but it will
> be a usability problem later on.
>
> LGTM.
>
> *From: *Jean Christophe Beyler <jcbeyler at google.com>
> *Date: *Tue, May 14, 2019 at 11:05 AM
> *To: *Arthur Eubanks
> *Cc: *Man Cao, <tsan-dev at openjdk.java.net>
>
> 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
>>
>