Symbolization

[Jean Christophe Beyler]

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