dblaikie added a comment. In D111981#3071378 <https://reviews.llvm.org/D111981#3071378>, @teemperor wrote:
> In D111981#3071349 <https://reviews.llvm.org/D111981#3071349>, @dblaikie > wrote: > >> So this'll add the right test dependency, if the libcxx project is enabled >> in the build? (& if the build hasn't enabled libcxx, the tests will run, but >> against the system compiler - and if that system compiler happens to default >> to libc++ ( >> https://github.com/llvm/llvm-project/blob/e9e4fc0fd3e0780207c731a1f2b8f6aacd24e8f8/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/list/TestDataFormatterLibcxxList.py#L49 >> )) that should remove the "different results if you run `ninja check-lldb` >> before or after `ninja check-libcxx`" issue? Great, thanks! >> >> Hmm, it doesn't appear to be working for me, running this (in a clean build >> directly, synced to 74c4d44d47b282769f6584153e9b433e8e5fa671 >> <https://reviews.llvm.org/rG74c4d44d47b282769f6584153e9b433e8e5fa671> which >> includes 366fb539485a9753e4a8167fe5140bf4fb00a098 >> <https://reviews.llvm.org/rG366fb539485a9753e4a8167fe5140bf4fb00a098> (& >> validated by inspecting `lldb/test/CMakeLists.txt`) still shows the tests as >> unsupported: >> >> CC=clang CXX=clang++ cmake -G Ninja -DCMAKE_BUILD_TYPE=Release >> -DLLVM_ENABLE_WERROR=true >> -DLLVM_ENABLE_PROJECTS='llvm;clang;clang-tools-extra;lld;lldb;cross-project-tests' >> -DLLVM_ENABLE_RUNTIMES='compiler-rt;libcxx;libcxxabi;libunwind' >> -DCMAKE_INSTALL_PREFIX=$HOME/install ~/dev/llvm/src/llvm >> ninja >> check-lldb-api-functionalities-data-formatter-data-formatter-stl-libcxx >> >> And then running `ninja cxx` and the same check again: >> >> ******************** >> FAIL: lldb-api :: >> functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py >> (23 of 23) >> ******************** TEST 'lldb-api :: >> functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py' >> FAILED ******************** >> Script: >> -- >> /usr/bin/python3.9 >> /usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/dotest.py -u >> CXXFLAGS -u CFLAGS --env ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy >> --env >> LLVM_LIBS_DIR=/usr/local/google/home/blaikie/dev/llvm/build/release/./lib >> --arch x86_64 --build-dir >> /usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex >> --lldb-module-cache-dir >> /usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex/module-cache-lldb/lldb-api >> --clang-module-cache-dir >> /usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex/module-cache-clang/lldb-api >> --executable >> /usr/local/google/home/blaikie/dev/llvm/build/release/./bin/lldb --compiler >> /usr/local/google/home/blaikie/dev/llvm/build/release/./bin/clang --dsymutil >> /usr/local/google/home/blaikie/dev/llvm/build/release/./bin/dsymutil >> --llvm-tools-dir /usr/local/google/home/blaikie/dev/llvm/build/release/./bin >> --lldb-libs-dir /usr/local/google/home/blaikie/dev/llvm/build/release/./lib >> /usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/set >> -p TestDataFormatterLibcxxSet.py >> -- >> Exit Code: 1 >> >> Command Output (stdout): >> -- >> lldb version 14.0.0 (g...@github.com:llvm/llvm-project.git revision >> 74c4d44d47b282769f6584153e9b433e8e5fa671) >> clang revision 74c4d44d47b282769f6584153e9b433e8e5fa671 >> llvm revision 74c4d44d47b282769f6584153e9b433e8e5fa671 >> Skipping the following test categories: ['dsym', 'gmodules', >> 'debugserver', 'objc'] >> >> -- >> Command Output (stderr): >> -- >> UNSUPPORTED: LLDB >> (/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang-x86_64) :: >> test_ref_and_ptr_dsym >> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase) (test case does >> not fall in any category of interest for this run) >> FAIL: LLDB >> (/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang-x86_64) :: >> test_ref_and_ptr_dwarf >> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase) >> FAIL: LLDB >> (/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang-x86_64) :: >> test_ref_and_ptr_dwo >> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase) >> UNSUPPORTED: LLDB >> (/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang-x86_64) :: >> test_ref_and_ptr_gmodules >> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase) (test case does >> not fall in any category of interest for this run) >> UNSUPPORTED: LLDB >> (/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang-x86_64) :: >> test_with_run_command_dsym >> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase) (test case does >> not fall in any category of interest for this run) >> FAIL: LLDB >> (/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang-x86_64) :: >> test_with_run_command_dwarf >> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase) >> FAIL: LLDB >> (/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang-x86_64) :: >> test_with_run_command_dwo >> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase) >> UNSUPPORTED: LLDB >> (/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang-x86_64) :: >> test_with_run_command_gmodules >> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase) (test case does >> not fall in any category of interest for this run) >> ====================================================================== >> FAIL: test_ref_and_ptr_dwarf >> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase) >> Test that the data formatters work on ref and ptr. >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/lldbtest.py", >> line 1823, in test_method >> return attrvalue(self) >> File >> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py", >> line 128, in test_ref_and_ptr >> (self.target, process, _, bkpt) = lldbutil.run_to_source_breakpoint( >> File >> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/lldbutil.py", >> line 970, in run_to_source_breakpoint >> return run_to_breakpoint_do_run(test, target, breakpoint, launch_info, >> File >> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/lldbutil.py", >> line 892, in run_to_breakpoint_do_run >> test.assertEqual(process.GetState(), lldb.eStateStopped) >> AssertionError: 10 != 5 >> >> Config=x86_64-/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang >> ====================================================================== >> FAIL: test_ref_and_ptr_dwo >> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase) >> Test that the data formatters work on ref and ptr. >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/lldbtest.py", >> line 1823, in test_method >> return attrvalue(self) >> File >> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py", >> line 128, in test_ref_and_ptr >> (self.target, process, _, bkpt) = lldbutil.run_to_source_breakpoint( >> File >> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/lldbutil.py", >> line 970, in run_to_source_breakpoint >> return run_to_breakpoint_do_run(test, target, breakpoint, launch_info, >> File >> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/lldbutil.py", >> line 892, in run_to_breakpoint_do_run >> test.assertEqual(process.GetState(), lldb.eStateStopped) >> AssertionError: 10 != 5 >> >> Config=x86_64-/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang >> ====================================================================== >> FAIL: test_with_run_command_dwarf >> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase) >> Test that that file and class static variables display correctly. >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/lldbtest.py", >> line 1823, in test_method >> return attrvalue(self) >> File >> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py", >> line 49, in test_with_run_command >> (self.target, process, _, bkpt) = lldbutil.run_to_source_breakpoint( >> File >> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/lldbutil.py", >> line 970, in run_to_source_breakpoint >> return run_to_breakpoint_do_run(test, target, breakpoint, launch_info, >> File >> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/lldbutil.py", >> line 892, in run_to_breakpoint_do_run >> test.assertEqual(process.GetState(), lldb.eStateStopped) >> AssertionError: 10 != 5 >> >> Config=x86_64-/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang >> ====================================================================== >> FAIL: test_with_run_command_dwo >> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase) >> Test that that file and class static variables display correctly. >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/lldbtest.py", >> line 1823, in test_method >> return attrvalue(self) >> File >> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py", >> line 49, in test_with_run_command >> (self.target, process, _, bkpt) = lldbutil.run_to_source_breakpoint( >> File >> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/lldbutil.py", >> line 970, in run_to_source_breakpoint >> return run_to_breakpoint_do_run(test, target, breakpoint, launch_info, >> File >> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/lldbutil.py", >> line 892, in run_to_breakpoint_do_run >> test.assertEqual(process.GetState(), lldb.eStateStopped) >> AssertionError: 10 != 5 >> >> Config=x86_64-/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang >> ---------------------------------------------------------------------- >> Ran 8 tests in 3.109s >> >> RESULT: FAILED (0 passes, 4 failures, 0 errors, 4 skipped, 0 expected >> failures, 0 unexpected successes) >> >> -- >> >> Any ideas? > > I think this is more of a speculative fix (the assert message doesn't have > that much information beside that the process crashes). Oh, mostly my point was "the output changes after I explicitly run `ninja cxx`" so it looks like the dependency didn't fully address the build consistency issue, regardless of what the failure actually is? > Can you apply https://reviews.llvm.org/D111978 and see what the error output > with that patch is? It should give you exit status/description and stderr. Sure, I'll give that a go (was going to test it once it was submitted), but emulating something similar to the test, by debugging the binary directly: $ ./bin/lldb ./lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/map/TestDataFormatterLibccMap.test_with_run_command_dwarf/a.out (lldb) target create "./lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/map/TestDataFormatterLibccMap.test_with_run_command_dwarf/a.out" Current executable set to '/usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/map/TestDataFormatterLibccMap.test_with_run_command_dwarf/a.out' (x86_64). (lldb) start error: 'start' is not a valid command. (lldb) r warning: (x86_64) /lib/x86_64-linux-gnu/ld-2.32.so Unable to initialize decompressor for section '.debug_abbrev': zlib is not available warning: (x86_64) /lib/x86_64-linux-gnu/ld-2.32.so Unable to initialize decompressor for section '.debug_info': zlib is not available Process 3723631 launched: '/usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/map/TestDataFormatterLibccMap.test_with_run_command_dwarf/a.out' (x86_64) warning: (x86_64) /lib/x86_64-linux-gnu/ld-2.32.so Unable to initialize decompressor for section '.debug_aranges': zlib is not available warning: (x86_64) /lib64/ld-linux-x86-64.so.2 Unable to initialize decompressor for section '.debug_abbrev': zlib is not available warning: (x86_64) /lib64/ld-linux-x86-64.so.2 Unable to initialize decompressor for section '.debug_info': zlib is not available /usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/map/TestDataFormatterLibccMap.test_with_run_command_dwarf/a.out: error while loading shared libraries: libc++.so.1: cannot open shared object file: No such file or directory I don't /think/ there's any reason (given the current Cmake configuration/code/etc) that the binary should be able to find libc++.so.1? In the libc++ tests (not the lldb libc++ tests, but the libc++ libc++ tests) they specify -rpath when compiling libc++ binaries against the just-built libc++ so they'll find the just-built libc++.so. I don't see anything like that in the lldb libc++ tests/build. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D111981/new/ https://reviews.llvm.org/D111981 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
