Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged
Hello, On 07/02/2018 21:51, Hans Wennborg via Release-testers wrote: > Dear testers, > > There's been a lot of merges since rc1, and hopefully the tests are in > a better state now. > > 6.0.0-rc2 was just tagged, after r324506. > > Please test, let me know how it goes, and upload binaries. Looks great on Debian. Bug 36051 (arm64 build issue) has been fixed. We did a rebuild of the Debian archive using 6.0rc1. I need to investigate the results but for now, I haven't seen anything crazy except a bug with qmake [1] (but not a regression on the clang side as I have the same issue with 5.0) Cheers, Sylvestre [1] https://bugreports.qt.io/browse/QTBUG-62531 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged
On Thu, Feb 8, 2018 at 10:43 PM, Dimitry Andric wrote: > On 7 Feb 2018, at 21:51, Hans Wennborg via Release-testers > wrote: >> >> There's been a lot of merges since rc1, and hopefully the tests are in >> a better state now. >> >> 6.0.0-rc2 was just tagged, after r324506. >> >> Please test, let me know how it goes, and upload binaries. > > Built, tested and uploaded: > > SHA256 (clang+llvm-6.0.0-rc2-amd64-unknown-freebsd10.tar.xz) = > 1334db5949ec0c78cd6e9b798f0b397fe9e99240d98bcfc834e4410258b98372 > SHA256 (clang+llvm-6.0.0-rc2-i386-unknown-freebsd10.tar.xz) = > a7c0b1e4cfe3d608ee77472c7f17fe6b9493c7259aca80fcdd3b8a4fe49ad92d > > On amd64-freebsd10 there were 896 unexpected test failures: > > Expected Passes: 45004 > Expected Failures : 186 > Unsupported Tests : 2939 > Unexpected Failures: 896 > > On i386-freebsd10 there were 619 unexpected test failures: > > Expected Passes: 43849 > Expected Failures : 195 > Unsupported Tests : 1954 > Unexpected Failures: 619 > > At least the i386 version looks quite a bit better, down from 1773 to 619 > test failures. :) What are all these test failures? Does it seems like they have a common root cause and do we have a bug for it? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [6.0.0 Release] Release Candidate 2 source, docs and binaries available
Hello everyone, Source, docs and binaries for LLVM-6.0.0-rc2 are now available at http://prereleases.llvm.org/6.0.0/#rc2 I'll add more binaries as they become available. Please report any problems you find, ideally as bugs marked as blockers of http://llvm.org/PR35804 Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged
W dniu śro, 07.02.2018 o godzinie 21∶51 +0100, użytkownik Hans Wennborg via Release-testers napisał: > Dear testers, > > There's been a lot of merges since rc1, and hopefully the tests are in > a better state now. > > 6.0.0-rc2 was just tagged, after r324506. > > Please test, let me know how it goes, and upload binaries. > RC2 looks much better on Gentoo. The only remaining failures are LLDB (as usual) and compiler-rt [1]. I've pushed the ebuilds without keywords for brave users who want to play with them. [1]:https://bugs.llvm.org/show_bug.cgi?id=36065 -- Best regards, Michał Górny ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged
> On 9 Feb 2018, at 10:20, Hans Wennborg wrote: > > On Thu, Feb 8, 2018 at 10:43 PM, Dimitry Andric wrote: >> On 7 Feb 2018, at 21:51, Hans Wennborg via Release-testers >> wrote: >>> >>> There's been a lot of merges since rc1, and hopefully the tests are in >>> a better state now. >>> >>> 6.0.0-rc2 was just tagged, after r324506. >>> >>> Please test, let me know how it goes, and upload binaries. >> >> Built, tested and uploaded: >> >> SHA256 (clang+llvm-6.0.0-rc2-amd64-unknown-freebsd10.tar.xz) = >> 1334db5949ec0c78cd6e9b798f0b397fe9e99240d98bcfc834e4410258b98372 >> SHA256 (clang+llvm-6.0.0-rc2-i386-unknown-freebsd10.tar.xz) = >> a7c0b1e4cfe3d608ee77472c7f17fe6b9493c7259aca80fcdd3b8a4fe49ad92d >> >> On amd64-freebsd10 there were 896 unexpected test failures: >> >> Expected Passes: 45004 >> Expected Failures : 186 >> Unsupported Tests : 2939 >> Unexpected Failures: 896 >> >> On i386-freebsd10 there were 619 unexpected test failures: >> >> Expected Passes: 43849 >> Expected Failures : 195 >> Unsupported Tests : 1954 >> Unexpected Failures: 619 >> >> At least the i386 version looks quite a bit better, down from 1773 to 619 >> test failures. :) > > What are all these test failures? Does it seems like they have a > common root cause and do we have a bug for it? There are multiple issues, some of which might be easily fixable, others have been there since a long time, and might be harder to fix. A full overview of the failures on amd64: Testing Time: 7907.21s Failing Tests (896): LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/DummyRPC.TestClearHandlers AddressSanitizer-Unit :: ./Asan-i386-calls-Test/AddressSanitizer.DoubleFreeTest AddressSanitizer-Unit :: ./Asan-i386-calls-Test/AddressSanitizer.ReallocFreedPointerTest AddressSanitizer-Unit :: ./Asan-i386-calls-Test/AddressSanitizer.UseThenFreeThenUseTest AddressSanitizer-Unit :: ./Asan-i386-calls-Test/AddressSanitizer.WrongFreeTest AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.DoubleFreeTest AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.UseThenFreeThenUseTest AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.WrongFreeTest AddressSanitizer-Unit :: ./Asan-x86_64-calls-Dynamic-Test/AddressSanitizer.DoubleFreeTest AddressSanitizer-Unit :: ./Asan-x86_64-calls-Dynamic-Test/AddressSanitizer.LongJmpTest AddressSanitizer-Unit :: ./Asan-x86_64-calls-Dynamic-Test/AddressSanitizer.ReallocFreedPointerTest AddressSanitizer-Unit :: ./Asan-x86_64-calls-Dynamic-Test/AddressSanitizer.SigLongJmpTest AddressSanitizer-Unit :: ./Asan-x86_64-calls-Dynamic-Test/AddressSanitizer.UnderscopeLongJmpTest AddressSanitizer-Unit :: ./Asan-x86_64-calls-Dynamic-Test/AddressSanitizer.UseThenFreeThenUseTest AddressSanitizer-Unit :: ./Asan-x86_64-calls-Dynamic-Test/AddressSanitizer.WrongFreeTest AddressSanitizer-Unit :: ./Asan-x86_64-calls-Dynamic-Test/AddressSanitizerInterface.HandleNoReturnTest AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test/AddressSanitizer.DoubleFreeTest AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test/AddressSanitizer.LongJmpTest AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test/AddressSanitizer.ReallocFreedPointerTest AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test/AddressSanitizer.SigLongJmpTest AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test/AddressSanitizer.UnderscopeLongJmpTest AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test/AddressSanitizer.UseThenFreeThenUseTest AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test/AddressSanitizer.WrongFreeTest AddressSanitizer-Unit :: ./Asan-x86_64-calls-Test/AddressSanitizerInterface.HandleNoReturnTest AddressSanitizer-Unit :: ./Asan-x86_64-inline-Dynamic-Test/AddressSanitizer.DoubleFreeTest AddressSanitizer-Unit :: ./Asan-x86_64-inline-Dynamic-Test/AddressSanitizer.ReallocFreedPointerTest AddressSanitizer-Unit :: ./Asan-x86_64-inline-Dynamic-Test/AddressSanitizer.UseThenFreeThenUseTest AddressSanitizer-Unit :: ./Asan-x86_64-inline-Dynamic-Test/AddressSanitizer.WrongFreeTest AddressSanitizer-Unit :: ./Asan-x86_64-inline-Dynamic-Test/AddressSanitizerInterface.HandleNoReturnTest AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test/AddressSanitizer.DoubleFreeTest AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test/AddressSanitizer.ReallocFreedPointerTest AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test/AddressSanitizer.UseThenFreeThenUseTest AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test/AddressSanitizer.WrongFreeTest AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test/AddressSanitizerInterface.HandleNoReturnTest AddressSanitizer-i386-freebsd :: TestCases/Posix/asan-sigbus.cpp AddressSanitizer-i386-freebsd :: TestCases/Pos
Re: [lldb-dev] [cfe-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged
On 9 Feb 2018, at 20:40, Dimitry Andric via cfe-dev wrote: > >> On 9 Feb 2018, at 10:20, Hans Wennborg wrote: ... >> What are all these test failures? Does it seems like they have a >> common root cause and do we have a bug for it? ... > The Clang Tools and Extra Tools Unit tests all appear to crash with: > >exception_ptr not yet implemented This turns out to be caused by libc++ being compiled without -DLIBCXXRT. (In the FreeBSD base system build, we always add this option, so libc++ knows how to handle exceptions.) In the libc++ CMakeFiles, it appears to be governed by LIBCXX_CXX_ABI_LIBNAME, but it isn't being set to the correct value of "cxxrt" on FreeBSD. I am going to try the following diff: --- llvm.src/projects/libcxx/CMakeLists.txt +++ llvm.src/projects/libcxx/CMakeLists.txt @@ -135,6 +135,8 @@ elseif (APPLE) set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi") set(LIBCXX_CXX_ABI_SYSTEM 1) + elseif (CMAKE_SYSTEM_NAME MATCHES "FreeBSD") +set(LIBCXX_CXX_ABI_LIBNAME "libcxxrt") else() set(LIBCXX_CXX_ABI_LIBNAME "default") endif() -Dimitry signature.asc Description: Message signed with OpenPGP ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Openmp-dev] [cfe-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged
On 9 Feb 2018, at 22:11, Dimitry Andric via Openmp-dev wrote: > > On 9 Feb 2018, at 20:40, Dimitry Andric via cfe-dev > wrote: >> >>> On 9 Feb 2018, at 10:20, Hans Wennborg wrote: > ... >>> What are all these test failures? Does it seems like they have a >>> common root cause and do we have a bug for it? > ... >> The Clang Tools and Extra Tools Unit tests all appear to crash with: >> >> exception_ptr not yet implemented > > This turns out to be caused by libc++ being compiled without -DLIBCXXRT. (In > the FreeBSD base system build, we always add this option, so libc++ knows how > to handle exceptions.) > > In the libc++ CMakeFiles, it appears to be governed by > LIBCXX_CXX_ABI_LIBNAME, but it isn't being set to the correct value of > "cxxrt" on FreeBSD. I am going to try the following diff: > > --- llvm.src/projects/libcxx/CMakeLists.txt > +++ llvm.src/projects/libcxx/CMakeLists.txt > @@ -135,6 +135,8 @@ > elseif (APPLE) > set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi") > set(LIBCXX_CXX_ABI_SYSTEM 1) > + elseif (CMAKE_SYSTEM_NAME MATCHES "FreeBSD") > +set(LIBCXX_CXX_ABI_LIBNAME "libcxxrt") > else() > set(LIBCXX_CXX_ABI_LIBNAME "default") > endif() ... and unfortunately that didn't work, since the CMakeFiles are unable to find the libcxxrt headers: CMake Warning at projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:67 (message): Failed to find cxxabi.h Call Stack (most recent call first): projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:112 (setup_abi_lib) projects/libcxx/CMakeLists.txt:428 (include) CMake Warning at projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:67 (message): Failed to find unwind.h Call Stack (most recent call first): projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:112 (setup_abi_lib) projects/libcxx/CMakeLists.txt:428 (include) CMake Warning at projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:67 (message): Failed to find unwind-arm.h Call Stack (most recent call first): projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:112 (setup_abi_lib) projects/libcxx/CMakeLists.txt:428 (include) CMake Warning at projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:67 (message): Failed to find unwind-itanium.h Call Stack (most recent call first): projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:112 (setup_abi_lib) projects/libcxx/CMakeLists.txt:428 (include) The problem is that on FreeBSD, these libcxxrt headers are installed into the same location as the base system's libc++ headers, which is /usr/include/c++/v1, and if I add that to the include path of libc++'s build, it will certainly cause conflicts. Does anybody have a suggestion on how this could be avoided? -Dimitry signature.asc Description: Message signed with OpenPGP ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 36331] New: Assertion failed: (idx < GetSize()), function GetItemAtIndex, file StructuredData.h, line 188
https://bugs.llvm.org/show_bug.cgi?id=36331 Bug ID: 36331 Summary: Assertion failed: (idx < GetSize()), function GetItemAtIndex, file StructuredData.h, line 188 Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: hiradi...@msn.com CC: llvm-b...@lists.llvm.org lldb Crashlog: Thread 3 Crashed:: lldb.debugger.event-handler 0 libsystem_kernel.dylib 0x7fff57bfce3e __pthread_kill + 10 1 libsystem_pthread.dylib 0x7fff57d3b150 pthread_kill + 333 2 libsystem_c.dylib 0x7fff57b59312 abort + 127 3 libsystem_c.dylib 0x7fff57b21368 __assert_rtn + 320 4 com.apple.LLDB.framework0x000104f32b18 lldb_private::StructuredData::Array::GetItemAtIndex(unsigned long) const + 100 5 com.apple.LLDB.framework0x000104d59bcd lldb_private::process_gdb_remote::ProcessGDBRemote::WillPublicStop() + 137 6 com.apple.LLDB.framework0x000104e23fae lldb_private::Process::ProcessEventData::DoOnRemoval(lldb_private::Event*) + 148 7 com.apple.LLDB.framework0x000104bf6a96 lldb_private::Listener::FindNextEventInternal(std::__1::unique_lock&, lldb_private::Broadca 8 com.apple.LLDB.framework0x000104bf6de5 lldb_private::Listener::GetEventInternal(lldb_private::Timeout > const&, lldb_ 9 com.apple.LLDB.framework0x000104bf716d lldb_private::Listener::GetEvent(std::__1::shared_ptr&, lldb_private::Timeout___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] hashing pointers to strings
DWARFDebugPubnamesSet.h has a type definition like this: typedef std::unordered_multimap, CStringEqualBinaryPredicate> cstr_to_index_mmap; In particular, note that the hasher will hash the *pointer *rather than the string it points to. It looks like this mostly works because the map is built once from string pointers that don't appear to be changed during the lifetime of the multimap. That's fragile, and I'm not sure it's really working in all cases. For example, there could be two different pointers to identical strings--since this is a multimap rather than a map, I assume we'd want those values merged under the same key, but since the pointers are distinct, they won't be. I'd like to change the key to a std::string or a StringRef for correctness and robustness, but that'll likely be a tad slower because hashing variable-length strings is more work than hashing fixed-length pointers. (I don't think it'll change comparisons much, since the comparator *is *checking the strings.) Objections or better suggestions? It's also hard for me to test, as most of the LLDB DWARF tests are still broken on Windows because the inferiors are generated with CodeView rather than DWARF. I'm working on that, but it'll take changes to the lld-link driver. Adrian. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] hashing pointers to strings
A quick glance indicates that this is all dead code. I can't see anything that actually instantiates either of the pubnames classes. The DWARF pubnames tables were a previous attempt at producing DWARF indexes, but they didn't contain enough information to actually forstall deep dives into the DWARF, so they weren't actually useful. clang doesn't emit them on macOS for sure, does it emit them on linux? They are superseded by the new DWARF 5 accelerator tables, and I couldn't find any reference to pubnames in the DWARF 5 draft standard. We should check with Greg about this, but I don't think we're ever likely to get any use out of DWARF pubnames tables. We should just delete this code. Jim > On Feb 9, 2018, at 4:35 PM, Adrian McCarthy via lldb-dev > wrote: > > DWARFDebugPubnamesSet.h has a type definition like this: > > typedef std::unordered_multimap std::hash, > CStringEqualBinaryPredicate> > cstr_to_index_mmap; > > In particular, note that the hasher will hash the pointer rather than the > string it points to. > > It looks like this mostly works because the map is built once from string > pointers that don't appear to be changed during the lifetime of the multimap. > That's fragile, and I'm not sure it's really working in all cases. For > example, there could be two different pointers to identical strings--since > this is a multimap rather than a map, I assume we'd want those values merged > under the same key, but since the pointers are distinct, they won't be. > > I'd like to change the key to a std::string or a StringRef for correctness > and robustness, but that'll likely be a tad slower because hashing > variable-length strings is more work than hashing fixed-length pointers. (I > don't think it'll change comparisons much, since the comparator is checking > the strings.) > > Objections or better suggestions? > > It's also hard for me to test, as most of the LLDB DWARF tests are still > broken on Windows because the inferiors are generated with CodeView rather > than DWARF. I'm working on that, but it'll take changes to the lld-link > driver. > > Adrian. > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
