[lldb-dev] Test suite failures on Fedora Linux?
Hello, I’m trying to build/test/run the latest lldb on the latest Red Hat Fedora, but I’m seeing four failures. Is this expected? What operating system do the LLVM build bots run? Thanks! Dave [1+3] Python script sym-linking LLDB Python API [1+2] Preparing lit tests [1+1] cd /home/dave/s/lc/clang/bindings/python && /usr/bin/cmake -E env CLANG_LIBRARY_PATH=/home/dave/s/lc/t/lib /usr/bin/python2.7 -m unittest discover ..LIBCLANG TOOLING ERROR: fixed-compilation-database: Error while opening fixed database: No such file or directory json-compilation-database: Error while opening JSON database: No such file or directory ..ss.s...s...s.s -- Ran 126 tests in 0.775s OK (skipped=6) [0+1] Running all regression tests llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using clang: /home/dave/s/lc/t/bin/clang llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using ld.lld: /home/dave/s/lc/t/bin/ld.lld llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using lld-link: /home/dave/s/lc/t/bin/lld-link llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using ld64.lld: /home/dave/s/lc/t/bin/ld64.lld llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using wasm-ld: /home/dave/s/lc/t/bin/wasm-ld llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using clang: /home/dave/s/lc/t/bin/clang llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using ld.lld: /home/dave/s/lc/t/bin/ld.lld llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using lld-link: /home/dave/s/lc/t/bin/lld-link llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using ld64.lld: /home/dave/s/lc/t/bin/ld64.lld llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using wasm-ld: /home/dave/s/lc/t/bin/wasm-ld llvm-lit: /home/dave/s/lc/t/utils/lit/tests/lit.cfg:67: note: Found python psutil module Deleting module cache at /home/dave/s/lc/t/./lib/../lldb-test-build.noindex/module-cache-clang. Deleting module cache at /home/dave/s/lc/t/./lib/../lldb-test-build.noindex/module-cache-lldb. -- Testing: 48524 tests, 96 threads -- Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90. FAIL: lldb-Suite :: expression_command/import-std-module/conflicts/TestStdModuleWithConflicts.py (47488 of 48524) TEST 'lldb-Suite :: expression_command/import-std-module/conflicts/TestStdModuleWithConflicts.py' FAILED lldb version 9.0.0 (https://git.llvm.org/git/lldb.git revision 1320ed17c93bf30b522dd71573a41e7d0a4950a8) clang revision 805d58dd43c1329590299f37ad2f48efbae3c78b llvm revision 6e821f01513dd49ed1668b65d10b2dbd07801d39 LLDB library dir: /home/dave/s/lc/t/bin LLDB import library dir: /home/dave/s/lc/t/bin Skipping following debug info categories: ['dsym', 'gmodules'] Session logs for test failures/errors/unexpected successes will go into directory '/home/dave/s/lc/t/lldb-test-traces' Command invoked: /home/dave/s/lc/lldb/test/dotest.py -q --arch=x86_64 -s /home/dave/s/lc/t/lldb-test-traces --build-dir /home/dave/s/lc/t/lldb-test-build.noindex -S nm -u CXXFLAGS -u CFLAGS --executable /home/dave/s/lc/t/./bin/lldb --dsymutil /home/dave/s/lc/t/./bin/dsymutil --filecheck /home/dave/s/lc/t/./bin/FileCheck -C /home/dave/s/lc/t/./bin/clang --env ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy --env LLVM_LIBS_DIR=/home/dave/s/lc/t/./lib /home/dave/s/lc/lldb/packages/Python/lldbsuite/test/expression_command/import-std-module/conflicts -p TestStdModuleWithConflicts.py UNSUPPORTED: LLDB (/home/dave/s/lc/t/bin/clang-9-x86_64) :: test_dsym (TestStdModuleWithConflicts.TestImportStdModuleConflicts) (test case does not fall in any category of interest for this run) FAIL: LLDB (/home/dave/s/lc/t/bin/clang-9-x86_64) :: test_dwarf (TestStdModuleWithConflicts.TestImportStdModuleConflicts) UNSUPPORTED: LLDB (/home/dave/s/lc/t/bin/clang-9-x86_64) :: test_dwo (TestStdModuleWithConflicts.TestImportStdModuleConflicts) (skipping due to the following parameter(s): debug info format) UNSUPPORTED: LLDB (/home/dave/s/lc/t/bin/clang-9-x86_64) :: test_gmodules (TestStdModuleWithConflicts.TestImportStdModuleConflicts) (test case does not fall in any category of interest for this run) == FAIL: test_dwarf (TestStdModuleWithConflicts.TestImportStdModuleConflicts) -- Traceback (most recent call last): File "/home/dave/s/lc/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1746, in test_method return attrvalue(self) File "/home/dave/s/lc/lldb/packages/Python/lldbsuite/test/decorators.py", line 144, in wrapper
Re: [lldb-dev] Test suite failures on Fedora Linux?
> On Mar 25, 2019, at 9:04 AM, Jan Kratochvil wrote: > > On Mon, 25 Mar 2019 12:05:33 +0100, David Zarzycki via lldb-dev wrote: >> I’m trying to build/test/run the latest lldb on the latest Red Hat Fedora, >> but I’m seeing four failures. Is this expected? What operating system do the >> LLVM build bots run? Thanks! > > My Fedora buildbot does run Fedora 29 x86_64 but it is a bit underpowered so > several racy testcases fail there, I need to fix those: > http://lab.llvm.org:8014/buildslaves/lldb-x86_64-fedora > > On my normal workstation I get PASS > (9ac2859cf2f2a47c8ec66ad4771bb35d627a789f). > kernel-4.20.15-200.fc29.x86_64 > Testing Time: 82.61s > Expected Passes: 1535 > Expected Failures : 1 > Unsupported Tests : 31 > [100%] Built target check-lldb > > As a form of troubleshooting you can try: > # dnf install elfutils-default-yama-scope;echo 0 > >/proc/sys/kernel/yama/ptrace_scope;setenforce 0 /proc/sys/kernel/yama/ptrace_scope is already set to zero, and SELinux is already disabled via the kernel command line. To answer Pavel’s related question, here is the kernel version: 5.0.3-200.fc29.x86_64 (mockbu...@bkernel03.phx2.fedoraproject.org) (gcc version 8.3.1 20190223 (Red Hat 8.3.1-2) (GCC)) #1 SMP Tue Mar 19 15:07:58 UTC 2019 ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Test suite failures on Fedora Linux?
> On Mar 25, 2019, at 12:26 PM, Jan Kratochvil > wrote: > > On Mon, 25 Mar 2019 14:11:09 +0100, David Zarzycki via lldb-dev wrote: >> 5.0.3-200.fc29.x86_64 (mockbu...@bkernel03.phx2.fedoraproject.org) (gcc >> version 8.3.1 20190223 (Red Hat 8.3.1-2) (GCC)) #1 SMP Tue Mar 19 15:07:58 >> UTC 2019 > > It does PASS here on: kernel-5.0.3-200.fc29.x86_64 > LLVM monorepo b833c6af5911ca71c555771097a03643660c1643 > > Failing Tests (1): >lldb-Suite :: functionalities/register/intel_avx/TestYMMRegister.py > Expected Passes: 1517 > Expected Failures : 1 > Unsupported Tests : 31 > Unexpected Failures: 1 > > That TestYMMRegister.py happens for me only in KVM virtualization guest, > unrelated to kernel version. I have never tried LLDB testsuite in KVM before, > I guess it is a KVM bug. > > https://github.com/llvm/llvm-project.git > time cmake ../llvm-monorepo/llvm/ -DCMAKE_BUILD_TYPE=Release > -DLLVM_USE_LINKER=gold -DLLVM_ENABLE_PROJECTS="lldb;clang;lld" > -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ > -DLLVM_ENABLE_ASSERTIONS=ON > make;make check-lldb > Hi Jan, I used above CMake setup (albeit with the pre-monorepo separate git repositories) and the four test failures still reproduced. Are you willing to share your CMakeCache.txt so that I might diff your setup with mine? Also, given that two of the test failures are Intel specific (the mxcsr register write failures), what class of hardware do you use? My workstation is Skylake-SP based, if it matters. Thanks, Dave ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Test suite failures on Fedora Linux?
> On Mar 26, 2019, at 3:07 AM, Jan Kratochvil wrote: > > On Mon, 25 Mar 2019 19:47:36 +0100, David Zarzycki via lldb-dev wrote: >> Also, given that two of the test failures are Intel specific (the mxcsr >> register write failures), what class of hardware do you use? My workstation >> is Skylake-SP based, if it matters. > > OK, I agree it PASSes for me on Haswell-EP (E5-2630v3) but it also FAILs for > me on Kaby Lake Refresh (i7-8650U). Also kernel-5.0.3-200.fc29.x86_64. It looks like this is a known issue: https://bugs.llvm.org/show_bug.cgi?id=39958 ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Test suite failures on Fedora Linux?
Hi Raphael, Any ETA on renaming the variables? The bug you mentioned also had someone offer to rename the variables in late 2017, but that seemingly never happened. Thanks! Dave > On Mar 25, 2019, at 7:25 AM, Raphael Isemann wrote: > > The import-std-module patches are probably just llvm.org/pr35043, so > I'll rename the variables there and that should fix it. Not sure about > the others. > > - Raphael > > Am Mo., 25. März 2019 um 12:06 Uhr schrieb David Zarzycki via lldb-dev > : >> >> Hello, >> >> I’m trying to build/test/run the latest lldb on the latest Red Hat Fedora, >> but I’m seeing four failures. Is this expected? What operating system do the >> LLVM build bots run? Thanks! >> >> Dave >> >> [1+3] Python script sym-linking LLDB Python API >> [1+2] Preparing lit tests >> [1+1] cd /home/dave/s/lc/clang/bindings/python && /usr/bin/cmake -E env >> CLANG_LIBRARY_PATH=/home/dave/s/lc/t/lib /usr/bin/python2.7 -m unittest >> discover >> ..LIBCLANG TOOLING >> ERROR: fixed-compilation-database: Error while opening fixed database: No >> such file or directory >> json-compilation-database: Error while opening JSON database: No such file >> or directory >> >> ..ss.s...s...s.s >> -- >> Ran 126 tests in 0.775s >> >> OK (skipped=6) >> [0+1] Running all regression tests >> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using >> clang: /home/dave/s/lc/t/bin/clang >> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using >> ld.lld: /home/dave/s/lc/t/bin/ld.lld >> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using >> lld-link: /home/dave/s/lc/t/bin/lld-link >> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using >> ld64.lld: /home/dave/s/lc/t/bin/ld64.lld >> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using >> wasm-ld: /home/dave/s/lc/t/bin/wasm-ld >> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using >> clang: /home/dave/s/lc/t/bin/clang >> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using >> ld.lld: /home/dave/s/lc/t/bin/ld.lld >> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using >> lld-link: /home/dave/s/lc/t/bin/lld-link >> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using >> ld64.lld: /home/dave/s/lc/t/bin/ld64.lld >> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using >> wasm-ld: /home/dave/s/lc/t/bin/wasm-ld >> llvm-lit: /home/dave/s/lc/t/utils/lit/tests/lit.cfg:67: note: Found python >> psutil module >> Deleting module cache at >> /home/dave/s/lc/t/./lib/../lldb-test-build.noindex/module-cache-clang. >> Deleting module cache at >> /home/dave/s/lc/t/./lib/../lldb-test-build.noindex/module-cache-lldb. >> -- Testing: 48524 tests, 96 threads -- >> Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90. >> FAIL: lldb-Suite :: >> expression_command/import-std-module/conflicts/TestStdModuleWithConflicts.py >> (47488 of 48524) >> TEST 'lldb-Suite :: >> expression_command/import-std-module/conflicts/TestStdModuleWithConflicts.py' >> FAILED >> lldb version 9.0.0 (https://git.llvm.org/git/lldb.git revision >> 1320ed17c93bf30b522dd71573a41e7d0a4950a8) >> clang revision 805d58dd43c1329590299f37ad2f48efbae3c78b >> llvm revision 6e821f01513dd49ed1668b65d10b2dbd07801d39 >> LLDB library dir: /home/dave/s/lc/t/bin >> LLDB import library dir: /home/dave/s/lc/t/bin >> Skipping following debug info categories: ['dsym', 'gmodules'] >> >> Session logs for test failures/errors/unexpected successes will go into >> directory '/home/dave/s/lc/t/lldb-test-traces' >> Command invoked: /home/dave/s/lc/lldb/test/dotest.py -q --arch=x86_64 -s >> /home/dave/s/lc/t/lldb-test-traces --build-dir >> /home/dave/s/lc/t/lldb-test-build.noindex -S nm -u CXXFLAGS -u CFLAGS >> --executable /home/dave/s/lc/t/./bin/lldb --dsymutil >> /home/dave/s/lc/t/./bin/dsymutil --filecheck >> /home/dave/s/lc/t/./bin/FileCheck -C /home/dave/s/lc/t/./bin/clang --env >> ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy --env >> LLVM_LIBS_DIR=/home/dave/s/lc/t/.
Re: [lldb-dev] [cfe-dev] [Openmp-dev] Instructions for requesting GitHub commit access
One is expected to use `git llvm push`. For more information, please see: https://llvm.org/docs/GettingStarted.html#for-developers-to-commit-changes-from-git > On Sep 3, 2019, at 7:06 PM, David Greene via cfe-dev > wrote: > > What is the expected way to do commits? Do we push directly to master > after a rebase? I know there has been talk of using GitHub pull > requests and I would be in favor of that. What's the status of those > discussions? > > -David > > Tom Stellard via Openmp-dev writes: > >> Hi, >> >> I've created a text file[1] in the SVN repository that developers can >> update in order to request commit access to the GitHub repository. >> All you need to do is add a line in the form of >> $SVN_USERNAME:$GITHUB_USERNAME >> >> Please add your information to this file before SVN becomes readonly >> on October 21 to avoid a gap in commit access. More details can be found in >> the phabriactor review[2] that updates the developer policy. >> >> We will be verifying that the svn committer matches the username in the >> file, so you can only request access for yourself and not someone else >> >> Thanks, >> Tom >> >> [1] >> https://llvm.org/viewvc/llvm-project/meta/trunk/github-usernames.txt?view=markup >> [2] https://reviews.llvm.org/D66840 >> ___ >> Openmp-dev mailing list >> openmp-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub Migration Schedule and Plans
> On Oct 14, 2019, at 9:15 PM, Renato Golin via llvm-dev > wrote: > > On Fri, 11 Oct 2019 at 00:22, Tom Stellard via llvm-dev > wrote: >> With my latest changes in https://reviews.llvm.org/D67772 it is actually >> possible >> to create a new branch with git-llvm, so we could print a disclaimer or >> block this, >> however we still can't stop people from creating a new branch using the >> normal git command. > > If the master branch is protected, we can always as people to be nice > and not create new branches and clean up if it happens by accident or > misinformation. > > After a while, mistakes should become infrequent enough that it's ok. > > FWIW, I'm with Mehdi on this. I'd much rather people used their own > forks for development branches, and leave only release branches on the > master repo. While I agree that people should create branches in their own forks, I’d also like to point out that one is not obligated to download everything from a given upstream repository. For example, if one only cares about master and release branches from LLVM but not tags or “random” branches, then one can change .git/config to look like this: [remote "truth"] url = https://github.com/llvm/llvm-project.git tagOpt = --no-tags fetch = +refs/heads/master:refs/remotes/truth/master fetch = +refs/heads/release/*:refs/remotes/truth/release/* ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] How soon after the GitHub migration should committing with git-llvm become optional?
I’d like to see it go away. For better and for worse, git is feature rich and that makes maintaining a wrapper script difficult. Personally speaking, I had to fix a git-llvm bug recently because it made flimsy assumptions about git remote names and how upstream tracking repositories work. > On Oct 15, 2019, at 10:47 AM, Marcus Johnson via llvm-dev > wrote: > > I say retire it instantly. > >> On Oct 15, 2019, at 3:14 AM, Tom Stellard via cfe-dev >> wrote: >> >> Hi, >> >> I mentioned this in my email last week, but I wanted to start a new >> thread to get everyone's input on what to do about the git-llvm script >> after the GitHub migration. >> >> The original plan was to require the use of the git-llvm script when >> committing to GitHub even after the migration was complete. >> The reason we decided to do this was so that we could prevent developers >> from accidentally pushing merge commits and making the history non-linear. >> >> Just in the last week, the GitHub team completed the "Require Linear >> History" branch protection, which means we can now enforce linear >> history server side and do not need the git-llvm script to do this. >> >> With this new development, the question I have is when should the >> git-llvm script become optional? Should we make it optional immediately, >> so that developers can push directly using vanilla git from day 1, or should >> we >> wait a few weeks/months until things have stabilized to make it optional? >> >> Thanks, >> Tom >> >> >> >> >> >> ___ >> cfe-dev mailing list >> cfe-...@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [libcxx-dev] [10.0.0 Release] The release branch is open; trunk is now 11.0.0
Hi Hans, FYI – https://reviews.llvm.org/D72980 > On Jan 15, 2020, at 9:34 AM, Hans Wennborg via libcxx-dev > wrote: > > Hello everyone, > > The release branch for LLVM 10 and its sub-projects was created from > trunk at e26a78e70857273c83aaacd4aa0edb36effe70e3, and the trunk > version was bumped to 11.0.0. > > Release blockers are tracked by https://llvm.org/PR44555 (hey, nice > number). Please mark any bugs, old or new, that need to be fixed > before the release as blocking that. > > Please keep me in the loop on any bugs, commits, or other issues you > think might be relevant for the release. In particular, if you're > currently investigating issues with trunk and working on fixes, please > let me know because we want those fixes on the branch too. > > To get a change committed to the branch, first commit it to trunk as > usual, and then request it to be merged -- ideally by filing a blocker > of https://llvm.org/PR44555, or by cc'ing me on the commit email. > (Please don't request merges over IRC/Discord/Discourse; there's a > large risk that I'll miss it.) > > When the branch is in good enough shape, hopefully in a day or two, > the first release candidate (RC1) will be tagged and testing of that > can begin. The full schedule can be found under "Upcoming Releases" to > the right at https://llvm.org > > Cheers, > Hans > ___ > libcxx-dev mailing list > libcxx-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
