[8.0.0 Release] rc1 has been tagged

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

[8.0.0 Release] rc1 has been tagged

Дилян Палаузов via cfe-dev
Dear testers,

8.0.0-rc1 was just tagged (from the branch at r351980).

It took a little longer than planned, but it's looking good.

Please run the test script, share your results, and upload binaries.

I'll get the source tarballs and docs published as soon as possible,
and binaries as they become available.

Thanks,
Hans
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [8.0.0 Release] rc1 has been tagged

Дилян Палаузов via cfe-dev
On Wed, Jan 23, 2019 at 4:49 PM Hans Wennborg <[hidden email]> wrote:

>
> Dear testers,
>
> 8.0.0-rc1 was just tagged (from the branch at r351980).
>
> It took a little longer than planned, but it's looking good.
>
> Please run the test script, share your results, and upload binaries.
>
> I'll get the source tarballs and docs published as soon as possible,
> and binaries as they become available.

The sources and docs are ready: https://prereleases.llvm.org/8.0.0/
Binaries will be uploaded as they become available.

Thanks,
Hans
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Release-testers] [8.0.0 Release] rc1 has been tagged

Дилян Палаузов via cfe-dev
In reply to this post by Дилян Палаузов via cfe-dev
On 24 Jan 2019, at 01:49, Hans Wennborg via Release-testers <[hidden email]> wrote:
>
> 8.0.0-rc1 was just tagged (from the branch at r351980).
>
> It took a little longer than planned, but it's looking good.
>
> Please run the test script, share your results, and upload binaries.

Unfortunately I'm running into a problem with check-all, where it fails to link XRayTest-x86_64-Test:

[100%] Generating XRayTest-x86_64-Test
/home/dim/llvm/8.0.0/rc1/Phase3/Release/llvmCore-8.0.0-rc1.obj/./lib/libLLVMSupport.a(Signals.cpp.o): In function `llvm::sys::PrintStackTrace(llvm::raw_ostream&)':
Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x24): undefined reference to `backtrace'
Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x254): undefined reference to `llvm::itaniumDemangle(char const*, char*, unsigned long*, int*)'
clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[3]: *** [projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build.make:73: projects/compiler-rt/lib/xray/tests/unit/XRayTest-x86_64-Test] Error 1
gmake[3]: Target 'projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build' not remade because of errors.
gmake[2]: *** [CMakeFiles/Makefile2:33513: projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/all] Error 2
gmake[2]: Target 'CMakeFiles/check-all.dir/all' not remade because of errors.
gmake[1]: *** [CMakeFiles/Makefile2:737: CMakeFiles/check-all.dir/rule] Error 2
gmake[1]: Target 'check-all' not remade because of errors.
gmake: *** [Makefile:277: check-all] Error 2
[Release Phase3] check-all failed

It appears this is because -lexecinfo is not passed to the link command line, but I'm unsure why this only seems to affect the XRay test.  I'm investigating, but if anybody has a cluestick, please hit me. :-)

-Dimitry


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (230 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Release-testers] [8.0.0 Release] rc1 has been tagged

Дилян Палаузов via cfe-dev
In reply to this post by Дилян Палаузов via cfe-dev
On Wed, 2019-01-23 at 16:49 -0800, Hans Wennborg via Release-testers
wrote:
> Dear testers,
>
> 8.0.0-rc1 was just tagged (from the branch at r351980).
>
> It took a little longer than planned, but it's looking good.
>
> Please run the test script, share your results, and upload binaries.
>

At this point, it looks very bad, with last-minute breaking changes
being added before the branching.

With Linux amd64 stand-alone builds, I have the following regressions:

- compiler-rt & LLDB fail at cmake when tests are enabled [1],

- libc++ fails to run tests [2].

Additionally, on (32-bit) x86:

- (llvm) JSONTest.Integers fails when built with newer versions
  of gcc [3],

- (clang) CXX/dcl.dcl/dcl.attr/dcl.align/p8.cpp fails [4].

I suppose that's as far as I can go with the current level of breakage.

I'll reply with NetBSD results later.


[1]:https://bugs.llvm.org/show_bug.cgi?id=40443
[2]:https://bugs.llvm.org/show_bug.cgi?id=40445
[3]:https://bugs.llvm.org/show_bug.cgi?id=40274
[4]:https://bugs.llvm.org/show_bug.cgi?id=40449


--
Best regards,
Michał Górny

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Release-testers] [8.0.0 Release] rc1 has been tagged

Дилян Палаузов via cfe-dev
In reply to this post by Дилян Палаузов via cfe-dev
On Thu, 2019-01-24 at 19:58 +0100, Dimitry Andric via Release-testers
wrote:

> On 24 Jan 2019, at 01:49, Hans Wennborg via Release-testers <[hidden email]> wrote:
> >
> > 8.0.0-rc1 was just tagged (from the branch at r351980).
> >
> > It took a little longer than planned, but it's looking good.
> >
> > Please run the test script, share your results, and upload binaries.
>
> Unfortunately I'm running into a problem with check-all, where it fails to link XRayTest-x86_64-Test:
>
> [100%] Generating XRayTest-x86_64-Test
> /home/dim/llvm/8.0.0/rc1/Phase3/Release/llvmCore-8.0.0-rc1.obj/./lib/libLLVMSupport.a(Signals.cpp.o): In function `llvm::sys::PrintStackTrace(llvm::raw_ostream&)':
> Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x24): undefined reference to `backtrace'
> Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x254): undefined reference to `llvm::itaniumDemangle(char const*, char*, unsigned long*, int*)'
> clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
> gmake[3]: *** [projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build.make:73: projects/compiler-rt/lib/xray/tests/unit/XRayTest-x86_64-Test] Error 1
> gmake[3]: Target 'projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build' not remade because of errors.
> gmake[2]: *** [CMakeFiles/Makefile2:33513: projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/all] Error 2
> gmake[2]: Target 'CMakeFiles/check-all.dir/all' not remade because of errors.
> gmake[1]: *** [CMakeFiles/Makefile2:737: CMakeFiles/check-all.dir/rule] Error 2
> gmake[1]: Target 'check-all' not remade because of errors.
> gmake: *** [Makefile:277: check-all] Error 2
> [Release Phase3] check-all failed
>
> It appears this is because -lexecinfo is not passed to the link command line, but I'm unsure why this only seems to affect the XRay test.  I'm investigating, but if anybody has a cluestick, please hit me. :-)
>
We've been having similar issue on NetBSD in the past.  Long story
short, the code around there is not using CMake rules to build stuff but
a custom compiler invocation, and therefore it does not inherit library
dependencies from CMake.

Short-term solution is to figure out what's missing and add it, with
appropriate conditionals.

Long-term solution (which is probably not suitable for 8.0.0) is to
rewrite that whole stuff.  Probably could work by creating a custom
language for CMake that's like C but uses just-built clang, etc.
However, that's just my theory and I'm not 100% sure it'll work or how
much work it'd involve.

--
Best regards,
Michał Górny

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Release-testers] [8.0.0 Release] rc1 has been tagged

Дилян Палаузов via cfe-dev
On 24 Jan 2019, at 20:34, Michał Górny <[hidden email]> wrote:

>
> On Thu, 2019-01-24 at 19:58 +0100, Dimitry Andric via Release-testers
> wrote:
>> On 24 Jan 2019, at 01:49, Hans Wennborg via Release-testers <[hidden email]> wrote:
>>>
>>> 8.0.0-rc1 was just tagged (from the branch at r351980).
>>>
>>> It took a little longer than planned, but it's looking good.
>>>
>>> Please run the test script, share your results, and upload binaries.
>>
>> Unfortunately I'm running into a problem with check-all, where it fails to link XRayTest-x86_64-Test:
>>
>> [100%] Generating XRayTest-x86_64-Test
>> /home/dim/llvm/8.0.0/rc1/Phase3/Release/llvmCore-8.0.0-rc1.obj/./lib/libLLVMSupport.a(Signals.cpp.o): In function `llvm::sys::PrintStackTrace(llvm::raw_ostream&)':
>> Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x24): undefined reference to `backtrace'
>> Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x254): undefined reference to `llvm::itaniumDemangle(char const*, char*, unsigned long*, int*)'
>> clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
>> gmake[3]: *** [projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build.make:73: projects/compiler-rt/lib/xray/tests/unit/XRayTest-x86_64-Test] Error 1
>> gmake[3]: Target 'projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build' not remade because of errors.
>> gmake[2]: *** [CMakeFiles/Makefile2:33513: projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/all] Error 2
>> gmake[2]: Target 'CMakeFiles/check-all.dir/all' not remade because of errors.
>> gmake[1]: *** [CMakeFiles/Makefile2:737: CMakeFiles/check-all.dir/rule] Error 2
>> gmake[1]: Target 'check-all' not remade because of errors.
>> gmake: *** [Makefile:277: check-all] Error 2
>> [Release Phase3] check-all failed
>>
>> It appears this is because -lexecinfo is not passed to the link command line, but I'm unsure why this only seems to affect the XRay test.  I'm investigating, but if anybody has a cluestick, please hit me. :-)
>>
>
> We've been having similar issue on NetBSD in the past.  Long story
> short, the code around there is not using CMake rules to build stuff but
> a custom compiler invocation, and therefore it does not inherit library
> dependencies from CMake.
>
> Short-term solution is to figure out what's missing and add it, with
> appropriate conditionals.
Yes, I'm attempting again with this diff applied:

--- llvm.src/projects/compiler-rt/cmake/config-ix.cmake
+++ llvm.src/projects/compiler-rt/cmake/config-ix.cmake
@@ -118,6 +118,7 @@ check_library_exists(dl dlopen "" COMPIL
 check_library_exists(rt shm_open "" COMPILER_RT_HAS_LIBRT)
 check_library_exists(m pow "" COMPILER_RT_HAS_LIBM)
 check_library_exists(pthread pthread_create "" COMPILER_RT_HAS_LIBPTHREAD)
+check_library_exists(execinfo backtrace "" COMPILER_RT_HAS_LIBEXECINFO)

 # Look for terminfo library, used in unittests that depend on LLVMSupport.
 if(LLVM_ENABLE_TERMINFO)
--- llvm.src/projects/compiler-rt/lib/xray/tests/CMakeLists.txt
+++ llvm.src/projects/compiler-rt/lib/xray/tests/CMakeLists.txt
@@ -71,13 +71,14 @@ if (NOT APPLE)
     endforeach()

     # We also add the actual libraries to link as dependencies.
-    list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport -lLLVMTestingSupport)
+    list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport -lLLVMDemangle -lLLVMTestingSupport)
   endif()

   append_list_if(COMPILER_RT_HAS_LIBM -lm XRAY_UNITTEST_LINK_FLAGS)
   append_list_if(COMPILER_RT_HAS_LIBRT -lrt XRAY_UNITTEST_LINK_FLAGS)
   append_list_if(COMPILER_RT_HAS_LIBDL -ldl XRAY_UNITTEST_LINK_FLAGS)
   append_list_if(COMPILER_RT_HAS_LIBPTHREAD -pthread XRAY_UNITTEST_LINK_FLAGS)
+  append_list_if(COMPILER_RT_HAS_LIBEXECINFO -lexecinfo XRAY_UNITTEST_LINK_FLAGS)
 endif()

 macro(add_xray_unittest testname)


Now the next problem is a Asan:DEADLYSIGNAL which keeps on repeating endlessly. :-)

-Dimitry


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (230 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [8.0.0 Release] rc1 has been tagged

Дилян Палаузов via cfe-dev
In reply to this post by Дилян Палаузов via cfe-dev
For compiler-rt and/or LLDB: is anyone else running into "FileCheck
target does not exist"?
https://bugs.llvm.org/show_bug.cgi?id=40443

Will try and figure it out tomorrow morning (in a few hours).

Best
Stefan

Am 24.01.19 um 01:49 schrieb Hans Wennborg via llvm-dev:

> Dear testers,
>
> 8.0.0-rc1 was just tagged (from the branch at r351980).
>
> It took a little longer than planned, but it's looking good.
>
> Please run the test script, share your results, and upload binaries.
>
> I'll get the source tarballs and docs published as soon as possible,
> and binaries as they become available.
>
> Thanks,
> Hans
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

--
https://weliveindetail.github.io/blog/
https://cryptup.org/pub/stefan.graenitz@...

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Release-testers] [8.0.0 Release] rc1 has been tagged

Дилян Палаузов via cfe-dev
In reply to this post by Дилян Палаузов via cfe-dev

Le 24/01/2019 à 01:49, Hans Wennborg via Release-testers a écrit :
> Dear testers,
>
> 8.0.0-rc1 was just tagged (from the branch at r351980).

Looks good on Debian & Ubuntu (Disco) on all supported archs (still
waiting for mipsel & mipsel64 but I am confident):

https://buildd.debian.org/status/package.php?p=llvm-toolchain-8&suite=experimental

https://launchpad.net/ubuntu/+source/llvm-toolchain-8/1:8~+rc1-1~exp1/

Note that it is now using a stage2 build (from -7) and that -8 will NOT
ship with Debian Buster.

I will try to dig a bit more into testsuite results.

S

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Release-testers] [8.0.0 Release] rc1 has been tagged

Дилян Палаузов via cfe-dev
In reply to this post by Дилян Палаузов via cfe-dev
Hi,
working without immediately obvious regressions on OpenMandriva x86-64, x86, aarch64 and armv7hnl.
Since our 4.0 release is imminent, 8.0 won't go in there, but it will be our main compiler the day after the release and been cut.

Would be nice to get the admin goto patches in to enable building the Linux kernel, but unfortunately that may be too big a change after RC?

ttyl
bero

On Thu, Jan 24, 2019, 3:50 AM Hans Wennborg via Release-testers <[hidden email] wrote:
Dear testers,

8.0.0-rc1 was just tagged (from the branch at r351980).

It took a little longer than planned, but it's looking good.

Please run the test script, share your results, and upload binaries.

I'll get the source tarballs and docs published as soon as possible,
and binaries as they become available.

Thanks,
Hans
_______________________________________________
Release-testers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Release-testers] [8.0.0 Release] rc1 has been tagged

Дилян Палаузов via cfe-dev
Uploaded AArch64 binaries:
2c3bd3d686c3712ba5699e9a638bc849ddb0aae3
clang+llvm-8.0.0-rc1-aarch64-linux-gnu.tar.xz

Had one failure in check-all (memory sanitizer). I opened PR40511 for it [1].

I ran into some snags with ARM, I'm still figuring out if there's
something wrong with our infrastructure. Sorry about the delay!

Cheers,
Diana

[1] https://bugs.llvm.org/show_bug.cgi?id=40511

On Tue, 29 Jan 2019 at 00:23, Bero Rosenkränzer via Release-testers
<[hidden email]> wrote:

>
> Hi,
> working without immediately obvious regressions on OpenMandriva x86-64, x86, aarch64 and armv7hnl.
> Since our 4.0 release is imminent, 8.0 won't go in there, but it will be our main compiler the day after the release and been cut.
>
> Would be nice to get the admin goto patches in to enable building the Linux kernel, but unfortunately that may be too big a change after RC?
>
> ttyl
> bero
>
> On Thu, Jan 24, 2019, 3:50 AM Hans Wennborg via Release-testers <[hidden email] wrote:
>>
>> Dear testers,
>>
>> 8.0.0-rc1 was just tagged (from the branch at r351980).
>>
>> It took a little longer than planned, but it's looking good.
>>
>> Please run the test script, share your results, and upload binaries.
>>
>> I'll get the source tarballs and docs published as soon as possible,
>> and binaries as they become available.
>>
>> Thanks,
>> Hans
>> _______________________________________________
>> Release-testers mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
> _______________________________________________
> Release-testers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Release-testers] [8.0.0 Release] rc1 has been tagged

Дилян Палаузов via cfe-dev
In reply to this post by Дилян Палаузов via cfe-dev
On Mon, Jan 28, 2019 at 6:23 PM Bero Rosenkränzer
<[hidden email]> wrote:
>
> Hi,
> working without immediately obvious regressions on OpenMandriva x86-64, x86, aarch64 and armv7hnl.
> Since our 4.0 release is imminent, 8.0 won't go in there, but it will be our main compiler the day after the release and been cut.
>
> Would be nice to get the admin goto patches in to enable building the Linux kernel, but unfortunately that may be too big a change after RC?

I'm definitely still open to considering those for llvm 8. I think it
depends on what they look like in the end, and when they land. But
they'll have to land on trunk first :-)

Thanks,
Hans

> On Thu, Jan 24, 2019, 3:50 AM Hans Wennborg via Release-testers <[hidden email] wrote:
>>
>> Dear testers,
>>
>> 8.0.0-rc1 was just tagged (from the branch at r351980).
>>
>> It took a little longer than planned, but it's looking good.
>>
>> Please run the test script, share your results, and upload binaries.
>>
>> I'll get the source tarballs and docs published as soon as possible,
>> and binaries as they become available.
>>
>> Thanks,
>> Hans
>> _______________________________________________
>> Release-testers mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Release-testers] [8.0.0 Release] rc1 has been tagged

Дилян Палаузов via cfe-dev
In reply to this post by Дилян Палаузов via cfe-dev

SLES and Ubuntu 14.04 tarballs uploaded.   Sorry for the delay.  I will try and find time to make a build for bionic / 18.04 too.

99ec00702e39b096ace4fbce3d787b9e485b879e  clang+llvm-8.0.0-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz

dbf204f70cb09ec459e5eb4fc14e8fa71292daa7  clang+llvm-8.0.0-rc1-x86_64-linux-sles11.3.tar.xz


On Wed, Jan 23, 2019 at 6:50 PM Hans Wennborg via Release-testers <[hidden email]> wrote:
Dear testers,

8.0.0-rc1 was just tagged (from the branch at r351980).

It took a little longer than planned, but it's looking good.

Please run the test script, share your results, and upload binaries.

I'll get the source tarballs and docs published as soon as possible,
and binaries as they become available.

Thanks,
Hans
_______________________________________________
Release-testers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers


--
-Brian

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Release-testers] [8.0.0 Release] rc1 has been tagged

Дилян Палаузов via cfe-dev
ARM looks good. Uploaded.

358fc71b8021eddbb1b93142bc09f1ad698677a6
clang+llvm-8.0.0-rc1-armv7a-linux-gnueabihf.tar.xz

Cheers,
Diana

On Wed, 30 Jan 2019 at 05:45, Brian Cain via Release-testers
<[hidden email]> wrote:

>
>
> SLES and Ubuntu 14.04 tarballs uploaded.   Sorry for the delay.  I will try and find time to make a build for bionic / 18.04 too.
>
> 99ec00702e39b096ace4fbce3d787b9e485b879e  clang+llvm-8.0.0-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz
>
> dbf204f70cb09ec459e5eb4fc14e8fa71292daa7  clang+llvm-8.0.0-rc1-x86_64-linux-sles11.3.tar.xz
>
>
> On Wed, Jan 23, 2019 at 6:50 PM Hans Wennborg via Release-testers <[hidden email]> wrote:
>>
>> Dear testers,
>>
>> 8.0.0-rc1 was just tagged (from the branch at r351980).
>>
>> It took a little longer than planned, but it's looking good.
>>
>> Please run the test script, share your results, and upload binaries.
>>
>> I'll get the source tarballs and docs published as soon as possible,
>> and binaries as they become available.
>>
>> Thanks,
>> Hans
>> _______________________________________________
>> Release-testers mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
>
>
> --
> -Brian
> _______________________________________________
> Release-testers mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Release-testers] [8.0.0 Release] rc1 has been tagged

Дилян Палаузов via cfe-dev
In reply to this post by Дилян Палаузов via cfe-dev
On 24 Jan 2019, at 21:25, Dimitry Andric via Release-testers <[hidden email]> wrote:
>
> On 24 Jan 2019, at 20:34, Michał Górny <[hidden email]> wrote:
>>
>> On Thu, 2019-01-24 at 19:58 +0100, Dimitry Andric via Release-testers wrote:
>>> On 24 Jan 2019, at 01:49, Hans Wennborg via Release-testers <[hidden email]> wrote:
>>>>
>>>> 8.0.0-rc1 was just tagged (from the branch at r351980).
...

> Yes, I'm attempting again with this diff applied:
>
> --- llvm.src/projects/compiler-rt/cmake/config-ix.cmake
> +++ llvm.src/projects/compiler-rt/cmake/config-ix.cmake
> @@ -118,6 +118,7 @@ check_library_exists(dl dlopen "" COMPIL
> check_library_exists(rt shm_open "" COMPILER_RT_HAS_LIBRT)
> check_library_exists(m pow "" COMPILER_RT_HAS_LIBM)
> check_library_exists(pthread pthread_create "" COMPILER_RT_HAS_LIBPTHREAD)
> +check_library_exists(execinfo backtrace "" COMPILER_RT_HAS_LIBEXECINFO)
>
> # Look for terminfo library, used in unittests that depend on LLVMSupport.
> if(LLVM_ENABLE_TERMINFO)
> --- llvm.src/projects/compiler-rt/lib/xray/tests/CMakeLists.txt
> +++ llvm.src/projects/compiler-rt/lib/xray/tests/CMakeLists.txt
> @@ -71,13 +71,14 @@ if (NOT APPLE)
>     endforeach()
>
>     # We also add the actual libraries to link as dependencies.
> -    list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport -lLLVMTestingSupport)
> +    list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport -lLLVMDemangle -lLLVMTestingSupport)
>   endif()
>
>   append_list_if(COMPILER_RT_HAS_LIBM -lm XRAY_UNITTEST_LINK_FLAGS)
>   append_list_if(COMPILER_RT_HAS_LIBRT -lrt XRAY_UNITTEST_LINK_FLAGS)
>   append_list_if(COMPILER_RT_HAS_LIBDL -ldl XRAY_UNITTEST_LINK_FLAGS)
>   append_list_if(COMPILER_RT_HAS_LIBPTHREAD -pthread XRAY_UNITTEST_LINK_FLAGS)
> +  append_list_if(COMPILER_RT_HAS_LIBEXECINFO -lexecinfo XRAY_UNITTEST_LINK_FLAGS)
> endif()
>
> macro(add_xray_unittest testname)
Meanwhile, this diff was applied, but I had little time to look at the tests again.  As I mentioned in my previous email, I saw many tests failing with an Asan:DEADLYSIGNAL error, which kept on endlessly repeating, until my log files filled up.

This is specifically happening during the dynamic ASan tests, e.g. Asan-x86_64-calls-Dynamic-Test and Asan-x86_64-inline-Dynamic-Test.  Running these in gdb shows that it gets into an endless recursion:

Starting program: /home/dim/obj/llvm-trunk-r352660/projects/compiler-rt/lib/asan/tests/dynamic/Asan-x86_64-inline-Dynamic-Test

Program received signal SIGSEGV, Segmentation fault.
0x000000080097bff1 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
408           reinterpret_cast<AsanThreadContext *>(AsanTSDGet());
(gdb) bt
#0  0x000000080097bff1 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
#1  0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
#2  0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
#3  0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
#4  0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
#5  0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
#6  0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
#7  0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
#8  0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
#9  0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
#10 0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
#11 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
#12 0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
#13 0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
#14 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
#15 0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
[...goes on until gdb crashes :)...]

The __tls_get_addr interceptor in sanitizer_common_interceptors.inc has a comment block which may indicate where the root cause lies:

  5096  // If you see any crashes around this functions, there are 2 known issues with
  5097  // it: 1. __tls_get_addr can be called with mis-aligned stack due to:
  5098  // https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
  5099  // 2. It can be called recursively if sanitizer code uses __tls_get_addr
  5100  // to access thread local variables (it should not happen normally,
  5101  // because sanitizers use initial-exec tls model).
  5102  INTERCEPTOR(void *, __tls_get_addr, void *arg) {
  5103    void *ctx;
  5104    COMMON_INTERCEPTOR_ENTER(ctx, __tls_get_addr, arg);

It looks like case 2 is happening here.  On FreeBSD and NetBSD, there is a special implementation in lib/asan/asan_posix.cc for AsanTSD functions:

    43  #if SANITIZER_NETBSD || SANITIZER_FREEBSD
    44  // Thread Static Data cannot be used in early init on NetBSD and FreeBSD.
    45  // Reuse the Asan TSD API for compatibility with existing code
    46  // with an alternative implementation.
    47
    48  static void (*tsd_destructor)(void *tsd) = nullptr;
[...]
    67  void *AsanTSDGet() {
    68    CHECK(tsd_destructor);
    69    return key.key;
    70  }

Since 'key' is a thread_local variable, the compiler inserts a call to __tls_get_addr:

_ZN6__asan10AsanTSDGetEv:               # @_ZN6__asan10AsanTSDGetEv
.Lfunc_begin4:
        .loc    2 66 0                  # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:66:0
        .cfi_startproc
# %bb.0:
        .loc    2 67 142 prologue_end   # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67:142
        pushq   %rax
        .cfi_def_cfa_offset 16
        cmpq    $0, _ZN6__asanL14tsd_destructorE(%rip)
        .loc    2 67 117 is_stmt 0      # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67:117
        je      .LBB4_4
# %bb.1:
        .loc    2 68 10 is_stmt 1       # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68:10
        leaq    __tls_guard@TLSLD(%rip), %rdi
        callq   __tls_get_addr@PLT
        movq    %rax, %rcx
        movb    __tls_guard@DTPOFF(%rcx), %cl
.Ltmp8:
        .file   4 "asan_posix.cc"
        .loc    4 0 0 is_stmt 0         # asan_posix.cc:0:0
        testb   %cl, %cl
        je      .LBB4_2
.Ltmp9:
.LBB4_3:                                # %_ZTWN6__asanL3keyE.exit
        .loc    2 68 14                 # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68:14
        movq    _ZN6__asanL3keyE@GOTTPOFF(%rip), %rax
        movq    %fs:0, %rcx
        movq    (%rcx,%rax), %rax
        .loc    2 68 3                  # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68:3
        popq    %rcx
        retq

The first call to AsanTSDGet is from within AsanInitInternal(), via OnMap() and GetCurrentThreadStats():

#0  AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67
#1  0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
#2  0x0000000800979fc6 in GetCurrentThreadStats () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_stats.cc:117
#3  0x00000008008f43ad in OnMap () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_allocator.cc:190
#4  MapWithCallbackOrDie () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_primary64.h:647
#5  Init () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_primary64.h:83
#6  0x00000008008f23cc in InitLinkerInitialized () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_combined.h:37
#7  InitLinkerInitialized () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_allocator.cc:281
#8  0x00000008009781cc in AsanInitInternal () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_rtl.cc:470
#9  0x000000080094a644 in __interceptor_readlink () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:6897
#10 0x0000000801532bbc in malloc_conf_init () at jemalloc_jemalloc.c:917
#11 malloc_init_hard_a0_locked () at jemalloc_jemalloc.c:1285
#12 0x0000000801532518 in malloc_init_hard () at jemalloc_jemalloc.c:1521
#13 malloc_init () at jemalloc_jemalloc.c:221
#14 jemalloc_constructor () at jemalloc_jemalloc.c:3285
#15 0x00000008008600eb in objlist_call_init (list=<optimized out>, lockstate=<optimized out>) at /usr/src/libexec/rtld-elf/rtld.c:2677
#16 0x000000080085ef3c in _rtld (sp=<optimized out>, exit_proc=0x7fffffffe5c0, objp=0x7fffffffe5c8) at /usr/src/libexec/rtld-elf/rtld.c:744
#17 0x000000080085d019 in .rtld_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:39

The second call is still within AsanInitInternal(), but via CreateMainThread() and SetCurrentThread():

#0  AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67
#1  0x000000080097b86e in SetCurrentThread () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:432
#2  0x000000080097b80f in __asan::CreateMainThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:280
#3  0x000000080097821a in AsanInitInternal () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_rtl.cc:496
[...]

The third call is the start of the endless recursion:

#0  AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67
#1  0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
#2  0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
#3  0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
#4  0x000000080097b86e in SetCurrentThread () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:432
#5  0x000000080097b80f in __asan::CreateMainThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:280
#6  0x000000080097821a in AsanInitInternal () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_rtl.cc:496
[...]

and continuing:

#0  AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67
#1  0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
#2  0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
#3  0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
#4  0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
#5  0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
#6  0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
#7  0x000000080097b86e in SetCurrentThread () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:432
#8  0x000000080097b80f in __asan::CreateMainThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:280
#9  0x000000080097821a in AsanInitInternal () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_rtl.cc:496
[...]

I'm not entirely sure when this behavior changed, since I seem to remember that it did work properly during the 7.0.0 and 7.0.1 release testing.  So I will have to bisect.

But if anybody has a clue where the endless recursion was introduced, or even better, how to fix it, please let us know.

-Dimitry


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (230 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Release-testers] [8.0.0 Release] rc1 has been tagged

Дилян Палаузов via cfe-dev
[trimming some lists since this otherwise gets binned as moderation material]

> On 2 Feb 2019, at 15:04, Dimitry Andric <[hidden email]> wrote:
> On 24 Jan 2019, at 21:25, Dimitry Andric via Release-testers <[hidden email]> wrote:
>>
>> On 24 Jan 2019, at 20:34, Michał Górny <[hidden email]> wrote:
>>>
>>> On Thu, 2019-01-24 at 19:58 +0100, Dimitry Andric via Release-testers wrote:
>>>> On 24 Jan 2019, at 01:49, Hans Wennborg via Release-testers <[hidden email]> wrote:
>>>>>
>>>>> 8.0.0-rc1 was just tagged (from the branch at r351980).
> ...
>> Yes, I'm attempting again with this diff applied:
>>
>> --- llvm.src/projects/compiler-rt/cmake/config-ix.cmake
>> +++ llvm.src/projects/compiler-rt/cmake/config-ix.cmake
>> @@ -118,6 +118,7 @@ check_library_exists(dl dlopen "" COMPIL
>> check_library_exists(rt shm_open "" COMPILER_RT_HAS_LIBRT)
>> check_library_exists(m pow "" COMPILER_RT_HAS_LIBM)
>> check_library_exists(pthread pthread_create "" COMPILER_RT_HAS_LIBPTHREAD)
>> +check_library_exists(execinfo backtrace "" COMPILER_RT_HAS_LIBEXECINFO)
>>
>> # Look for terminfo library, used in unittests that depend on LLVMSupport.
>> if(LLVM_ENABLE_TERMINFO)
>> --- llvm.src/projects/compiler-rt/lib/xray/tests/CMakeLists.txt
>> +++ llvm.src/projects/compiler-rt/lib/xray/tests/CMakeLists.txt
>> @@ -71,13 +71,14 @@ if (NOT APPLE)
>>    endforeach()
>>
>>    # We also add the actual libraries to link as dependencies.
>> -    list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport -lLLVMTestingSupport)
>> +    list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport -lLLVMDemangle -lLLVMTestingSupport)
>>  endif()
>>
>>  append_list_if(COMPILER_RT_HAS_LIBM -lm XRAY_UNITTEST_LINK_FLAGS)
>>  append_list_if(COMPILER_RT_HAS_LIBRT -lrt XRAY_UNITTEST_LINK_FLAGS)
>>  append_list_if(COMPILER_RT_HAS_LIBDL -ldl XRAY_UNITTEST_LINK_FLAGS)
>>  append_list_if(COMPILER_RT_HAS_LIBPTHREAD -pthread XRAY_UNITTEST_LINK_FLAGS)
>> +  append_list_if(COMPILER_RT_HAS_LIBEXECINFO -lexecinfo XRAY_UNITTEST_LINK_FLAGS)
>> endif()
>>
>> macro(add_xray_unittest testname)
>
> Meanwhile, this diff was applied, but I had little time to look at the tests again.  As I mentioned in my previous email, I saw many tests failing with an Asan:DEADLYSIGNAL error, which kept on endlessly repeating, until my log files filled up.
>
> This is specifically happening during the dynamic ASan tests, e.g. Asan-x86_64-calls-Dynamic-Test and Asan-x86_64-inline-Dynamic-Test.  Running these in gdb shows that it gets into an endless recursion:
>
> Starting program: /home/dim/obj/llvm-trunk-r352660/projects/compiler-rt/lib/asan/tests/dynamic/Asan-x86_64-inline-Dynamic-Test
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000080097bff1 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
> 408           reinterpret_cast<AsanThreadContext *>(AsanTSDGet());
> (gdb) bt
> #0  0x000000080097bff1 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
> #1  0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
> #2  0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
> #3  0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
> #4  0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
> #5  0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
> #6  0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
> #7  0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
> #8  0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
> #9  0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
> #10 0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
> #11 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
> #12 0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
> #13 0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
> #14 0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
> #15 0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
> [...goes on until gdb crashes :)...]
>
> The __tls_get_addr interceptor in sanitizer_common_interceptors.inc has a comment block which may indicate where the root cause lies:
>
>  5096  // If you see any crashes around this functions, there are 2 known issues with
>  5097  // it: 1. __tls_get_addr can be called with mis-aligned stack due to:
>  5098  // https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
>  5099  // 2. It can be called recursively if sanitizer code uses __tls_get_addr
>  5100  // to access thread local variables (it should not happen normally,
>  5101  // because sanitizers use initial-exec tls model).
>  5102  INTERCEPTOR(void *, __tls_get_addr, void *arg) {
>  5103    void *ctx;
>  5104    COMMON_INTERCEPTOR_ENTER(ctx, __tls_get_addr, arg);
>
> It looks like case 2 is happening here.  On FreeBSD and NetBSD, there is a special implementation in lib/asan/asan_posix.cc for AsanTSD functions:
>
>    43  #if SANITIZER_NETBSD || SANITIZER_FREEBSD
>    44  // Thread Static Data cannot be used in early init on NetBSD and FreeBSD.
>    45  // Reuse the Asan TSD API for compatibility with existing code
>    46  // with an alternative implementation.
>    47
>    48  static void (*tsd_destructor)(void *tsd) = nullptr;
> [...]
>    67  void *AsanTSDGet() {
>    68    CHECK(tsd_destructor);
>    69    return key.key;
>    70  }
>
> Since 'key' is a thread_local variable, the compiler inserts a call to __tls_get_addr:
>
> _ZN6__asan10AsanTSDGetEv:               # @_ZN6__asan10AsanTSDGetEv
> .Lfunc_begin4:
>        .loc    2 66 0                  # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:66:0
>        .cfi_startproc
> # %bb.0:
>        .loc    2 67 142 prologue_end   # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67:142
>        pushq   %rax
>        .cfi_def_cfa_offset 16
>        cmpq    $0, _ZN6__asanL14tsd_destructorE(%rip)
>        .loc    2 67 117 is_stmt 0      # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67:117
>        je      .LBB4_4
> # %bb.1:
>        .loc    2 68 10 is_stmt 1       # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68:10
>        leaq    __tls_guard@TLSLD(%rip), %rdi
>        callq   __tls_get_addr@PLT
>        movq    %rax, %rcx
>        movb    __tls_guard@DTPOFF(%rcx), %cl
> .Ltmp8:
>        .file   4 "asan_posix.cc"
>        .loc    4 0 0 is_stmt 0         # asan_posix.cc:0:0
>        testb   %cl, %cl
>        je      .LBB4_2
> .Ltmp9:
> .LBB4_3:                                # %_ZTWN6__asanL3keyE.exit
>        .loc    2 68 14                 # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68:14
>        movq    _ZN6__asanL3keyE@GOTTPOFF(%rip), %rax
>        movq    %fs:0, %rcx
>        movq    (%rcx,%rax), %rax
>        .loc    2 68 3                  # /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68:3
>        popq    %rcx
>        retq
>
> The first call to AsanTSDGet is from within AsanInitInternal(), via OnMap() and GetCurrentThreadStats():
>
> #0  AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67
> #1  0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
> #2  0x0000000800979fc6 in GetCurrentThreadStats () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_stats.cc:117
> #3  0x00000008008f43ad in OnMap () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_allocator.cc:190
> #4  MapWithCallbackOrDie () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_primary64.h:647
> #5  Init () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_primary64.h:83
> #6  0x00000008008f23cc in InitLinkerInitialized () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_combined.h:37
> #7  InitLinkerInitialized () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_allocator.cc:281
> #8  0x00000008009781cc in AsanInitInternal () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_rtl.cc:470
> #9  0x000000080094a644 in __interceptor_readlink () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:6897
> #10 0x0000000801532bbc in malloc_conf_init () at jemalloc_jemalloc.c:917
> #11 malloc_init_hard_a0_locked () at jemalloc_jemalloc.c:1285
> #12 0x0000000801532518 in malloc_init_hard () at jemalloc_jemalloc.c:1521
> #13 malloc_init () at jemalloc_jemalloc.c:221
> #14 jemalloc_constructor () at jemalloc_jemalloc.c:3285
> #15 0x00000008008600eb in objlist_call_init (list=<optimized out>, lockstate=<optimized out>) at /usr/src/libexec/rtld-elf/rtld.c:2677
> #16 0x000000080085ef3c in _rtld (sp=<optimized out>, exit_proc=0x7fffffffe5c0, objp=0x7fffffffe5c8) at /usr/src/libexec/rtld-elf/rtld.c:744
> #17 0x000000080085d019 in .rtld_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:39
>
> The second call is still within AsanInitInternal(), but via CreateMainThread() and SetCurrentThread():
>
> #0  AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67
> #1  0x000000080097b86e in SetCurrentThread () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:432
> #2  0x000000080097b80f in __asan::CreateMainThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:280
> #3  0x000000080097821a in AsanInitInternal () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_rtl.cc:496
> [...]
>
> The third call is the start of the endless recursion:
>
> #0  AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67
> #1  0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
> #2  0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
> #3  0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
> #4  0x000000080097b86e in SetCurrentThread () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:432
> #5  0x000000080097b80f in __asan::CreateMainThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:280
> #6  0x000000080097821a in AsanInitInternal () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_rtl.cc:496
> [...]
>
> and continuing:
>
> #0  AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:67
> #1  0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
> #2  0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
> #3  0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
> #4  0x000000080097bff6 in __asan::GetCurrentThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:408
> #5  0x00000008009408b0 in __interceptor___tls_get_addr () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5107
> #6  0x0000000800973ad7 in AsanTSDGet () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:68
> #7  0x000000080097b86e in SetCurrentThread () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:432
> #8  0x000000080097b80f in __asan::CreateMainThread() () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_thread.cc:280
> #9  0x000000080097821a in AsanInitInternal () at /home/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_rtl.cc:496
> [...]
>
> I'm not entirely sure when this behavior changed, since I seem to remember that it did work properly during the 7.0.0 and 7.0.1 release testing.  So I will have to bisect.
>
> But if anybody has a clue where the endless recursion was introduced, or even better, how to fix it, please let us know.
It turns out this recursion was introduced by https://reviews.llvm.org/rL349619 ("Reimplement Thread Static Data ASan routines with TLS").  I was apparently subscribed to the review, but I seems to have totally missed it.

Trying the tree just before that revision, e.g. at r349618, also doesn't lead to success, since there it gets into an endless loop between internal_sysctlbyname() and __interceptor_sysctlbyname(), when a call to sysctlbyname() is intercepted during thread initialization:

#0  __sanitizer::internal_sysctlbyname(char const*, void*, unsigned long*, void const*, unsigned long) () at /home/dim/src/llvm/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:783
#1  0x00000008013e61a9 in init_private () at /usr/src/lib/libthr/thread/thr_init.c:478
#2  _libpthread_init (curthread=0x0) at /usr/src/lib/libthr/thread/thr_init.c:331
#3  0x00000008013df342 in _thr_check_init () at /usr/src/lib/libthr/thread/thr_private.h:927
#4  _pthread_key_create (key=0x801211a44 <__asan::tsd_key>, destructor=0x80095cc10 <__asan::PlatformTSDDtor(void*)>) at /usr/src/lib/libthr/thread/thr_spec.c:62
#5  0x000000080095cb43 in __asan::AsanTSDInit(void (*)(void*)) () at /home/dim/src/llvm/llvm-project/compiler-rt/lib/asan/asan_posix.cc:48
#6  0x0000000800961005 in AsanInitInternal () at /home/dim/src/llvm/llvm-project/compiler-rt/lib/asan/asan_rtl.cc:453
#7  0x0000000800944864 in __interceptor_readlink () at /home/dim/src/llvm/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:6880
#8  0x000000080151bbbc in malloc_conf_init () at jemalloc_jemalloc.c:917
#9  malloc_init_hard_a0_locked () at jemalloc_jemalloc.c:1285
#10 0x000000080151b518 in malloc_init_hard () at jemalloc_jemalloc.c:1521
#11 malloc_init () at jemalloc_jemalloc.c:221
#12 jemalloc_constructor () at jemalloc_jemalloc.c:3285
#13 0x000000080085e0eb in objlist_call_init (list=<optimized out>, lockstate=<optimized out>) at /usr/src/libexec/rtld-elf/rtld.c:2677
#14 0x000000080085cf3c in _rtld (sp=<optimized out>, exit_proc=0x7fffffffe5a0, objp=0x7fffffffe5a8) at /usr/src/libexec/rtld-elf/rtld.c:744
#15 0x000000080085b019 in .rtld_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:39

Apparently this was also broken somewhere in the past.  I don't believe dynamic ASan has worked correctly on FreeBSD for some time...

-Dimitry


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (230 bytes) Download Attachment