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!
[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
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 remaining two failures look like they're down to the linux kernel refusing to allow us to write some values into some registers.
David, what's the exact kernel version that you are running?
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:
On my normal workstation I get PASS (9ac2859cf2f2a47c8ec66ad4771bb35d627a789f).
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 (email@example.com) (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.
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
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.
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.
1 (28.9 KB)
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.
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
It looks like this is a known issue:
Ok, so I've managed to get a hold of a machine which reproduces this
problem. It's a debian based system running linux 4.19, which should
confirm that this is a hardware issue.
I'll try to find some time to diagnose this later this week. My guess is
that we're just setting some mxcsr value that these CPUs don't like, and
we need to be more conservative in what we write in the tests.
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.
I believe the rename that bug is referring to really did happen. What
you are seeing is a new test, which also uses "a" as a meaningless
I'll do the rename right away.
Sorry, was traveling and the internet wasn't good enough for git.
Thanks for pushing a fix Pavel!
Ok, the issue was a bit more complex than I anticipated, but I think I managed to create a patch <https://reviews.llvm.org/D59991> that fixes that, as well as prevents something similar from happening in the future (for the curious, a there's a longer description of the problem in the patch).
Jan, David, this patch was enough to fix the test suite failures on the machine that I got access to, but I'd appreciate it if you could check that it also fixes things on your end.