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

[Arthur Eubanks]

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
>