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