Symbolization

[Arthur Eubanks]

The earliest GCC that uses __tsan_symbolize_external_ex() is GCC 9. So
using the GCC version supported by OpenJDK (GCC 7) is not feasible.

I tried compiling GCC 9 and using it as the toolchain (install GCC 9 with
prefix $HOME/bin/gcc9, then configure and build OpenJDK
--with-toolchain-path=$HOME/bin/gcc9).

Running the TSAN tests, I get
result: Failed. Unexpected exit from test [exit code: 139]

Doing some searching, it looks like exit code 139 is something to do with
memory fragmentation, or SIGSEGV, or something like that. So my guess is
that mixing .so's between the Linux distro and the compiled GCC is not okay.

On Mon, Apr 29, 2019 at 2:48 PM Jean Christophe Beyler <jcbeyler at google.com>
wrote:

> FWIW, it does not really matter to me at this point what we say to do as
> long as it works for us. At some point, when we get a bit further along, we
> would want to figure out a "sane" way of doing things; requiring to compile
> GCC by hand is not sane in my opinion but is ok for now :)
> Jc
>
> On Mon, Apr 29, 2019 at 2:36 PM Man Cao <manc at google.com> wrote:
>
>> I think the best way is still to find a way to build libtsan.so from
>> latest source, with the GCC version supported by OpenJDK:
>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms.
>> Even if we can get libtsan.so from a newer GCC, I'm not sure if it is
>> safe to build OpenJDK with the newer GCC, or to use a newer libtsan.so with
>> an old GCC.
>>
>> -Man
>>
>>
>> On Mon, Apr 29, 2019 at 2:18 PM Jean Christophe Beyler <
>> jcbeyler at google.com> wrote:
>>
>>> Compiling gcc to get libtsan... Is there no way to build libtsan then
>>> from
>>> scratch instead?
>>>
>>> On Mon, Apr 29, 2019 at 2:00 PM Arthur Eubanks <aeubanks at google.com>
>>> wrote:
>>>
>>> > It looks like the libtsan.so from gcc 8 is out of date. It doesn't
>>> > contain __tsan_symbolize_external_ex(), only the
>>> > legacy __tsan_symbolize_external(). This messes with testing the Java
>>> Tsan
>>> > patches.
>>> >
>>> > $ strings /usr/lib/gcc/x86_64-linux-gnu/8/libtsan.so | grep __tsan_sym
>>> >
>>> > I looked at the latest gcc sources and it does have a version of Tsan
>>> that
>>> > includes __tsan_symbolize_external_ex(). We could tell people to
>>> compile
>>> > their own gcc and use that libtsan.so.
>>> > $ apt search gcc
>>> > only shows up to gcc 8 on my machine.
>>> >
>>> > Thoughts?
>>> >
>>>
>>>
>>> --
>>>
>>> Thanks,
>>> Jc
>>>
>>
>
> --
>
> Thanks,
> Jc
>