On Mon, Jan 7, 2019 at 9:08 PM Joel E. Denny <jdenny.o...@gmail.com> wrote:
> On Mon, Jan 7, 2019 at 11:39 AM Adrian Prantl <apra...@apple.com> wrote: > >> >> >> On Jan 7, 2019, at 8:28 AM, Joel E. Denny via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >> On Mon, Jan 7, 2019 at 11:15 AM Davide Italiano <dccitali...@gmail.com> >> wrote: >> >>> On Sat, Jan 5, 2019 at 9:48 AM Joel E. Denny via lldb-dev >>> <lldb-dev@lists.llvm.org> wrote: >>> > >>> > On Fri, Jan 4, 2019 at 11:39 AM Frédéric Riss <fr...@apple.com> wrote: >>> >> >>> >> >>> >> >>> >> > On Jan 4, 2019, at 7:30 AM, Joel E. Denny <jdenny.o...@gmail.com> >>> wrote: >>> >> > >>> >> > On Thu, Jan 3, 2019 at 11:30 AM Frédéric Riss <fr...@apple.com> >>> wrote: >>> >> > -llvm-dev + lldb-dev for the lldv test failures. >>> >> > >>> >> >> On Jan 3, 2019, at 7:33 AM, Joel E. Denny <jdenny.o...@gmail.com> >>> wrote: >>> >> >> >>> >> >> All, >>> >> >> >>> >> >> Thanks for the replies. Kuba: For LLDB, when were things expected >>> to have improved? It's possible things improved for me at some point, but >>> this isn't something I've found time to track carefully, and I still see >>> problems. >>> >> >> >>> >> >> I ran check-all a couple of times last night at r350238, which I >>> pulled yesterday. Here are the results: >>> >> >> >>> >> >> ``` >>> >> >> ******************** >>> >> >> Testing Time: 5043.24s >>> >> >> ******************** >>> >> >> Unexpected Passing Tests (2): >>> >> >> lldb-Suite :: functionalities/asan/TestMemoryHistory.py >>> >> >> lldb-Suite :: functionalities/asan/TestReportData.py >>> >> >> >>> >> >> ******************** >>> >> >> Failing Tests (54): >>> >> >> Clang :: CXX/modules-ts/basic/basic.link/p2/module.cpp >>> >> >> Clang :: Modules/ExtDebugInfo.cpp >>> >> >> Clang :: Modules/using-directive-redecl.cpp >>> >> >> Clang :: Modules/using-directive.cpp >>> >> >> Clang :: PCH/chain-late-anonymous-namespace.cpp >>> >> >> Clang :: PCH/cxx-namespaces.cpp >>> >> >> Clang :: PCH/namespaces.cpp >>> >> >> LLDB :: ExecControl/StopHook/stop-hook-threads.test >>> >> >> LeakSanitizer-AddressSanitizer-x86_64 :: TestCases/Linux/ >>> use_tls_dynamic.cc >>> >> >> LeakSanitizer-Standalone-x86_64 :: TestCases/Linux/ >>> use_tls_dynamic.cc >>> >> >> MemorySanitizer-X86_64 :: dtls_test.c >>> >> >> MemorySanitizer-lld-X86_64 :: dtls_test.c >>> >> >> lldb-Suite :: >>> functionalities/register/register_command/TestRegisters.py >>> >> >> lldb-Suite :: tools/lldb-server/TestGdbRemoteRegisterState.py >>> >> > >>> >> > It’s hard to diagnose dotest failures without the log. >>> >> > >>> >> > (My last reply to this was rejected by the list because I wasn't >>> subscribed. Trying again.) >>> >> > >>> >> > I have no experience debugging lldb. Here's the lit output for the >>> last fail (now at r350377), but let me know if you want something more: >>> >> > >>> >> > ``` >>> >> > FAIL: lldb-Suite :: tools/lldb-server/TestGdbRemoteRegisterState.py >>> (59083 of 59736) >>> >> > ******************** TEST 'lldb-Suite :: >>> tools/lldb-server/TestGdbRemoteRegisterState.py' FAILED ******************** >>> >> > lldb version 8.0.0 >>> >> > LLDB library dir: /home/jdenny/ornl/llvm-mono-git-build/bin >>> >> > LLDB import library dir: /home/jdenny/ornl/llvm-mono-git-build/bin >>> >> > Libc++ tests will not be run because: Unable to find libc++ >>> installation >>> >> > Skipping following debug info categories: ['dsym', 'gmodules'] >>> >> > >>> >> > Session logs for test failures/errors/unexpected successes will go >>> into directory '/home/jdenny/ornl/llvm-mono-git-build/lldb-test-traces' >>> >> > Command invoked: >>> /home/jdenny/ornl/llvm-mono-git/lldb/test/dotest.py -q --arch=x86_64 -s >>> /home/jdenny/ornl/llvm-mono-git-build/lldb-test-traces --build-dir >>> /home/jdenny/ornl/llvm-mono-git-build/lldb-test-build.noindex -S nm -u >>> CXXFLAGS -u CFLAGS --executable >>> /home/jdenny/ornl/llvm-mono-git-build/./bin/lldb --dsymutil >>> /home/jdenny/ornl/llvm-mono-git-build/./bin/dsymutil --filecheck >>> /home/jdenny/ornl/llvm-mono-git-build/./bin/FileCheck -C >>> /home/jdenny/ornl/llvm-mono-git-build/./bin/clang --env >>> ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy >>> /home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server >>> -p TestGdbRemoteRegisterState.py >>> >> > UNSUPPORTED: LLDB >>> (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) :: >>> test_grp_register_save_restore_works_no_suffix_debugserver >>> (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) (debugserver tests) >>> >> > FAIL: LLDB >>> (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) :: >>> test_grp_register_save_restore_works_no_suffix_llgs >>> (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) >>> >> > lldb-server exiting... >>> >> > UNSUPPORTED: LLDB >>> (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) :: >>> test_grp_register_save_restore_works_with_suffix_debugserver >>> (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) (debugserver tests) >>> >> > FAIL: LLDB >>> (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) :: >>> test_grp_register_save_restore_works_with_suffix_llgs >>> (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) >>> >> > lldb-server exiting... >>> >> > >>> ====================================================================== >>> >> > FAIL: test_grp_register_save_restore_works_no_suffix_llgs >>> (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) >>> >> > >>> ---------------------------------------------------------------------- >>> >> > Traceback (most recent call last): >>> >> > File >>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/decorators.py", >>> line 144, in wrapper >>> >> > func(*args, **kwargs) >>> >> > File >>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py", >>> line 137, in test_grp_register_save_restore_works_no_suffix_llgs >>> >> > self.grp_register_save_restore_works(USE_THREAD_SUFFIX) >>> >> > File >>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py", >>> line 97, in grp_register_save_restore_works >>> >> > context = self.expect_gdbremote_sequence() >>> >> > File >>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py", >>> line 713, in expect_gdbremote_sequence >>> >> > self.logger) >>> >> > File >>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", >>> line 261, in expect_lldb_gdbserver_replay >>> >> > asserter, content, context=context) >>> >> > File >>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", >>> line 564, in assert_match >>> >> > self._assert_exact_payload_match(asserter, actual_packet) >>> >> > File >>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", >>> line 518, in _assert_exact_payload_match >>> >> > assert_packets_equal(asserter, actual_packet, >>> self.exact_payload) >>> >> > File >>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", >>> line 159, in assert_packets_equal >>> >> > asserter.assertEqual(actual_stripped, expected_stripped) >>> >> > AssertionError: '$E77' != '$OK' >>> >> > Config=x86_64-/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8 >>> >> > >>> ====================================================================== >>> >> > FAIL: test_grp_register_save_restore_works_with_suffix_llgs >>> (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) >>> >> > >>> ---------------------------------------------------------------------- >>> >> > Traceback (most recent call last): >>> >> > File >>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/decorators.py", >>> line 144, in wrapper >>> >> > func(*args, **kwargs) >>> >> > File >>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py", >>> line 121, in test_grp_register_save_restore_works_with_suffix_llgs >>> >> > self.grp_register_save_restore_works(USE_THREAD_SUFFIX) >>> >> > File >>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py", >>> line 97, in grp_register_save_restore_works >>> >> > context = self.expect_gdbremote_sequence() >>> >> > File >>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py", >>> line 713, in expect_gdbremote_sequence >>> >> > self.logger) >>> >> > File >>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", >>> line 261, in expect_lldb_gdbserver_replay >>> >> > asserter, content, context=context) >>> >> > File >>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", >>> line 564, in assert_match >>> >> > self._assert_exact_payload_match(asserter, actual_packet) >>> >> > File >>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", >>> line 518, in _assert_exact_payload_match >>> >> > assert_packets_equal(asserter, actual_packet, >>> self.exact_payload) >>> >> > File >>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py", >>> line 159, in assert_packets_equal >>> >> > asserter.assertEqual(actual_stripped, expected_stripped) >>> >> > AssertionError: '$E77' != '$OK' >>> >> > Config=x86_64-/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8 >>> >> > >>> ---------------------------------------------------------------------- >>> >> > Ran 4 tests in 22.052s >>> >> >>> >> I’m not familiar with the lldb-server tests. Pavel might know what >>> Error 77 is? >>> >> >>> >> > RESULT: FAILED (0 passes, 2 failures, 0 errors, 2 skipped, 0 >>> expected failures, 0 unexpected successes) >>> >> > >>> >> > ******************** >>> >> > ``` >>> >> > >>> >> > >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestBorrowedReferences >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestDictionaryResolutionWithDot >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestExtractingUInt64ThroughStructuredData >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestGlobalNameResolutionNoDot >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestGlobalNameResolutionWithDot >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestInstanceNameResolutionNoDot >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestModuleNameResolutionNoDot >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestObjectAttributes >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestOwnedReferences >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonByteArray >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonBytes >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonCallableCheck >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonCallableInvoke >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonDictionaryManipulation >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonDictionaryToStructuredDictionary >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonDictionaryValueEquality >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonFile >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonInteger >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonIntegerToStr >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonIntegerToStructuredInteger >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonListManipulation >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonListToStructuredList >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonListValueEquality >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonString >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonStringToStr >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonStringToStructuredString >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleInitializerList >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleInitializerList2 >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleSize >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleToStructuredList >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleValues >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestResetting >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestTypeNameResolutionNoDot >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestAcquisitionSemantics >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestAutoRestoreChanged >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestAutoRestoreSemantics >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestDiscardSemantics >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestExceptionStateChecking >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestManualRestoreSemantics >>> >> >> lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestResetSemantics >>> >> > >>> >> > Those unit test failures don’t ring a bell. Anyone’s seen this? >>> Here too, knowing exactly the error message would help. >>> >> > >>> >> > Here's the lit output for the last one: >>> >> > >>> >> > ``` >>> >> > FAIL: lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestResetSemantics >>> (59324 of 59736) >>> >> > ******************** TEST 'lldb-Unit :: >>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestResetSemantics' >>> FAILED ******************** >>> >> > Note: Google Test filter = >>> PythonExceptionStateTest.TestResetSemantics >>> >> > [==========] Running 1 test from 1 test case. >>> >> > [----------] Global test environment set-up. >>> >> > [----------] 1 test from PythonExceptionStateTest >>> >> > [ RUN ] PythonExceptionStateTest.TestResetSemantics >>> >> > ScriptInterpreterPythonTests: >>> /home/jdenny/ornl/llvm-mono-git/llvm/include/llvm/Support/CommandLine.h:800: >>> void llvm::cl::parser<llvm::ScheduleDAGInstrs >>> *(*)(llvm::MachineSchedContext *)>::addLiteralOption(llvm::StringRef, const >>> DT &, llvm::StringRef) [DataType = llvm::ScheduleDAGInstrs >>> *(*)(llvm::MachineSchedContext *), DT = llvm::ScheduleDAGInstrs >>> *(*)(llvm::MachineSchedContext *)]: Assertion `findOption(Name) == >>> Values.size() && "Option already exists!"' failed. >>> >> >>> >> That’s interesting. It seems like some clots are registered twice. As >>> he backtrace shows that you have a libLLVMSupport.so, I could imagine this >>> happening if the unittest was linking with both a static version and the >>> dynamic version of the LLVM libraries, but that’s just a theory. I don’t >>> know how good the build system is at dealing with a libraries build of >>> LLVM, I wouldn’t be surprised if this is untested and thus broken. >>> > >>> > >>> > I rebuilt without -DBUILD_SHARED_LIBS=true, and all the previous >>> failing clang and lldb-Unit tests then passed (other test results did not >>> change). My build size jumped from 33G to 136G. I didn't pay attention to >>> the build time this time, but my past experience is that incremental builds >>> can be many times slower without -DBUILD_SHARED_LIBS=true. This does not >>> seem like a good solution for me. >>> > >>> > Joel >>> > >>> >>> I think the number of people using BUILD_SHARED_LIBS=True is >>> relatively limited, and there's no bot testing that configuration. >>> Stefan is the resident build expert, so he might be able to comment. >>> >> >> I see. So the large and slow builds are not a concern for most people? >> >> >> Not sure if this is what you are seeing but: Because of the way debug >> information is processed (or rather not processed by the linker), the link >> times of debug builds on macOS are much faster than on Linux, so at least >> for developers working on macOS this is not so much of an issue. On Linux >> you might want to enable split dwarf support to get similar speedups even >> for static links. >> > > With BUILD_SHARED_LIBS=True, LLVM_USE_SPLIT_DWARF=True drops the build > size from 33G to 24G. > With BUILD_SHARED_LIBS=False, LLVM_USE_SPLIT_DWARF=True drops the build > size from 136G to 71G. > > I also timed an incremental build after touching > clang/lib/Sema/SemaOpenMP.cpp. > With BUILD_SHARED_LIBS=True, LLVM_USE_SPLIT_DWARF=True drops the time from > ~50s to ~31s. > With BUILD_SHARED_LIBS=False, I only tried LLVM_USE_SPLIT_DWARF=True, and > the time is ~3m53s. > > So, LLVM_USE_SPLIT_DWARF=True definitely helps. Thanks! > > However, I prefer to recompile and test frequently during development, so > BUILD_SHARED_LIBS=True still offers a big advantage there: 7.5x faster > incremental build. > For anyone interested in the Clang side of this discussion (Clang test fails and incremental build times), I've started a new thread here: http://lists.llvm.org/pipermail/cfe-dev/2019-January/060755.html Joel > > Joel > > >> >> -- adrian >> >> Perhaps I need to do something else to prevent that. And perhaps I >> should ask this question again on cfe-dev given that most of my rebuilds >> affect clang. >> >> Thanks. >> >> Joel >> >> >>> -- >>> Davide >>> >> _______________________________________________ >> 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
