Symbolization

[Arthur Eubanks]

It seems like mixing system libraries and the custom GCC libraries at all
is bad.
With LD_DEBUG=libs, bin/java fails at
calling init: path/to/libstdc++.so.6
whether it's the system libstdc++ or the GCC libstdc++. Even only using the
libtsan.so from the custom GCC and no other libraries results in the same
problem.

I think we need a better solution. Maybe compiling just libtsan.so
ourselves.

On Tue, Apr 30, 2019 at 3:18 PM Arthur Eubanks <aeubanks at google.com> wrote:

> 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
>>
>