[klee-dev] Packaging klee on Nix - gtest broken?

Morgan me at numin.it
Sat Jan 8 22:49:07 GMT 2022


Somewhat related, I'm having trouble building KLEE on aarch64. Here's
the failing part:

-- Build files have been written to: /build/source/build
cmake: enabled parallel building
building
build flags: -j4 -l4
SHELL=/nix/store/fbf5n09drbi3bxv9rb9fgf58dm4da4a8-bash-5.1-p12/bin/bash
[  1%] Building CXX object lib/Basic/CMakeFiles/kleeBasic.dir/KTest.cpp.o
[  1%] Building CXX object
lib/Support/CMakeFiles/kleeSupport.dir/CompressionStream.cpp.o
[  1%] Building CXX object lib/Expr/CMakeFiles/kleaverExpr.dir/ArrayCache.cpp.o
[  1%] Building C object
runtime/Runtest/CMakeFiles/kleeRuntest.dir/intrinsics.c.o
[  1%] Building CXX object
runtime/Runtest/CMakeFiles/kleeRuntest.dir/__/__/lib/Basic/KTest.cpp.o
[  1%] Building CXX object lib/Basic/CMakeFiles/kleeBasic.dir/Statistics.cpp.o
[  1%] Linking CXX shared library ../../lib/libkleeRuntest.so
[  1%] Built target kleeRuntest
[  1%] Building CXX object
lib/Support/CMakeFiles/kleeSupport.dir/ErrorHandling.cpp.o
[  1%] Linking CXX static library ../libkleeBasic.a
[  1%] Built target kleeBasic
[  1%] Building CXX object
lib/Expr/CMakeFiles/kleaverExpr.dir/ArrayExprOptimizer.cpp.o
[  2%] Generating memset64_Release.bc
[  2%] Generating stubs64_Release.bc
[  2%] Building CXX object
lib/Support/CMakeFiles/kleeSupport.dir/FileHandling.cpp.o
[  2%] Generating fortify-fs64_Release.bc
[  2%] Generating memcmp64_Release.bc
[  2%] Generating fd64_Release.bc
[  3%] Generating memcpy64_Release.bc
/build/source/runtime/POSIX/fd.c:98:18: error: use of undeclared
identifier '__NR_access'
  return syscall(__NR_access, __concretize_string(pathname), mode);
                 ^
/build/source/runtime/POSIX/fd.c:194:25: error: use of undeclared
identifier '__NR_open'; did you mean '__fd_open'?
    int os_fd = syscall(__NR_open, __concretize_string(pathname), flags, mode);
                        ^~~~~~~~~
                        __fd_open
/build/source/runtime/POSIX/fd.c:141:5: note: '__fd_open' declared here
int __fd_open(const char *pathname, int flags, mode_t mode) {
    ^
/build/source/runtime/POSIX/fd.c:286:18: error: use of undeclared
identifier '__NR_utimes'
  return syscall(__NR_utimes, __concretize_string(path), times);
                 ^
/build/source/runtime/POSIX/fd.c:308:18: error: use of undeclared
identifier '__NR_futimesat'
  return syscall(__NR_futimesat, (long)fd,

<...>

Is there some syscall-relevant include I'm missing?

Morgan


On Sat, Jan 8, 2022 at 2:19 PM Morgan <me at numin.it> wrote:
>
> >Is this also the issue you ran into? If yes, maybe you want try the
> >patches from the PR I linked above. If not and are you having a
> >different problem, maybe you could try to provide some more details?
> >Then I will try and see if can help resolve them.
>
> This is the problem. No tests discovered. That patch fixed it, thanks a ton!
> Hydra will be running the full KLEE system and unit test suite from now on.
>
>
> Morgan
>
> On Wed, Jan 5, 2022 at 2:48 AM Cristian Cadar <c.cadar at imperial.ac.uk> wrote:
> >
> > Hi all,
> >
> > Indeed, it would be great to update
> > https://klee.github.io/getting-started/ (via a PR at
> > https://github.com/klee/klee.github.io) to mention the Fedora and Nix
> > packages.  And thanks to everyone who is maintaining KLEE packages!
> >
> > Best,
> > Cristian
> >
> > On 05/01/2022 10:01, Julian Büning wrote:
> > > Hi Lukas,
> > >
> > > nice and thanks for letting me know!
> > >
> > > I was briefly considering to go the same route, but didn't encounter
> > > your fix. But as it turns out, not using gtest_main (which I understand
> > > is more or less offered for convenience) has certain other advantages
> > > for KLEE (e.g. stack traces; reducing the number of combinations between
> > > vanilla Google Test, LLVM's Google Test, llvm-lit, and their respective
> > > versions). Still, it's certainly a nice addition for llvm-lit, hopefully
> > > somebody with commit access will pick it up soon!
> > >
> > > Thanks to your email I also found out that there is actually a Fedora
> > > package for KLEE in the main repository. Awesome! I'm not sure how I
> > > missed that. You should definitely get it mentioned on klee.github.io!
> > >
> > > Best,
> > > Julian
> > >
> > > On 1/5/22 10:15, Lukas Zaoral wrote:
> > >> Hi Julian,
> > >> I've encountered the same problem with lit and latest gtest when
> > >> I was packaging KLEE for Fedora as I had to use gtest from repos
> > >> due to Fedora's packaging guidelines.
> > >>
> > >> I sent a patch to LLVM to fix this incompatibility at the beginning
> > >> of last April and it was finally accepted last month [1].  It still needs
> > >> to be committed, though.
> > >>
> > >> Sincerely,
> > >> Lukas
> > >>
> > >> [1] https://reviews.llvm.org/D100043
> > >>
> > >> On Wed, Jan 5, 2022 at 9:44 AM Julian Büning
> > >> <julian.buening at rwth-aachen.de> wrote:
> > >>>
> > >>> Hi Morgan,
> > >>>
> > >>> nice to see your packaging efforts for KLEE!
> > >>>
> > >>> I recently ran into some issues with more recent versions of Google Test
> > >>> when building KLEE (and running unit tests). I just opened a PR that
> > >>> addresses these: https://github.com/klee/klee/pull/1458
> > >>>
> > >>> Among these issues is one that I image you may also have run into (as I
> > >>> assume your package will not be built against Google Test 1.7.0), but it
> > >>> differs quite a bit from the issue that you linked. Thus, I will go
> > >>> ahead and describe what I experienced (hoping you can tell me if that
> > >>> matches what you saw).
> > >>>
> > >>> When building KLEE with Google Test 1.7.0 and running the unit tests, I
> > >>> get 36 successfully passed tests. When instead using a newer Google Test
> > >>> version, like 1.11.0, I get the same number of passed tests, but the
> > >>> following 10 unresolved tests in addition:
> > >>>
> > >>> Unresolved Tests (10):
> > >>>     KLEE Unit tests :: ./AssignmentTest/Running main() from
> > >>> /some/absolute/path/to/gtest_main.cc
> > >>>     KLEE Unit tests :: ./DiscretePDFTest/Running main() from
> > >>> /some/absolute/path/to/gtest_main.cc
> > >>>     KLEE Unit tests :: ./ExprTest/Running main() from
> > >>> /some/absolute/path/to/gtest_main.cc
> > >>>     KLEE Unit tests :: ./RNGTest/Running main() from
> > >>> /some/absolute/path/to/gtest_main.cc
> > >>>     KLEE Unit tests :: ./RefTest/Running main() from
> > >>> /some/absolute/path/to/gtest_main.cc
> > >>>     KLEE Unit tests :: ./SearcherTest/Running main() from
> > >>> /some/absolute/path/to/gtest_main.cc
> > >>>     KLEE Unit tests :: ./SolverTest/Running main() from
> > >>> /some/absolute/path/to/gtest_main.cc
> > >>>     KLEE Unit tests :: ./TimeTest/Running main() from
> > >>> /some/absolute/path/to/gtest_main.cc
> > >>>     KLEE Unit tests :: ./TreeStreamTest/Running main() from
> > >>> /some/absolute/path/to/gtest_main.cc
> > >>>     KLEE Unit tests :: ./Z3SolverTest/Running main() from
> > >>> /some/absolute/path/to/gtest_main.cc
> > >>>
> > >>> For each of these "tests" I see some earlier output like this:
> > >>>
> > >>> UNRESOLVED: KLEE Unit tests :: ./AssignmentTest/Running main() from
> > >>> /some/absolute/path/to/gtest_main.cc (1 of 46)
> > >>> ******************** TEST 'KLEE Unit tests :: ./AssignmentTest/Running
> > >>> main() from /some/absolute/path/to/gtest_main.cc' FAILED
> > >>> ********************
> > >>> Unable to find '[  PASSED  ] 1 test.' in gtest output:
> > >>>
> > >>> Running main() from /some/absolute/path/to/gtest_main.cc
> > >>> Note: Google Test filter = Running main() from
> > >>> /some/absolute/path/to/gtest_main.cc
> > >>> [==========] Running 0 tests from 0 test cases.
> > >>> [==========] 0 tests from 0 test cases ran. (0 ms total)
> > >>> [  PASSED  ] 0 tests.
> > >>>
> > >>> ********************
> > >>>
> > >>> The last 3 lines look similar to the output in the issue you linked. But
> > >>> this is simply the output of Google Test when there are no `TEST()`s
> > >>> next to `main()` in an executable. The rest stems from a different
> > >>> problem (detailed below).
> > >>>
> > >>> Is this also the issue you ran into? If yes, maybe you want try the
> > >>> patches from the PR I linked above. If not and are you having a
> > >>> different problem, maybe you could try to provide some more details?
> > >>> Then I will try and see if can help resolve them.
> > >>>
> > >>> --- BEGIN: More details ---
> > >>>
> > >>> The issue we see above actually stems from llvm-lit, not from Google
> > >>> Test itself. Starting from 1.8.1, Google Test's gtest_main.cc uses
> > >>> `__FILE__` [1] instead of a fixed string [2] to output a line like this:
> > >>>   > Running main() from /some/absolute/path/to/gtest_main.cc
> > >>>
> > >>> To determine which tests exist, llvm-lit will call each executable with
> > >>> the `--gtest_list_tests` argument. However, the (usually) first line
> > >>> will be the above "Running main()" output. To skip this, each line is
> > >>> compared to "Running main() from gtest_main.cc" [3], which is a fixed
> > >>> string assuming the behavior of 1.8.0 and before.
> > >>>
> > >>> Hence, the line with path will be recorded as a test, and result in a
> > >>> corresponding call to the test executable with `--gtest_filter` set
> > >>> accordingly. As there is no test that matches the given pattern, we see
> > >>> the output shown above. As it does not include the expected "[  PASSED
> > >>> ] 1 test." line, it is counted as unresolved.
> > >>>
> > >>> [1]
> > >>> https://github.com/google/googletest/blob/release-1.8.1/googletest/src/gtest_main.cc
> > >>>
> > >>>
> > >>> [2]
> > >>> https://github.com/google/googletest/blob/release-1.8.0/googletest/src/gtest_main.cc
> > >>>
> > >>>
> > >>> [3]
> > >>> https://github.com/llvm/llvm-project/blob/llvmorg-13.0.0/llvm/utils/lit/lit/formats/googletest.py#L60-L64
> > >>>
> > >>>
> > >>> --- END:   More details ---
> > >>>
> > >>> Looking forward to your answer!
> > >>>
> > >>> Best,
> > >>> Julian
> > >>>
> > >>>
> > >>>
> > >>> On 1/1/22 01:28, Morgan wrote:
> > >>>> Hey there,
> > >>>>
> > >>>> I like Klee and have been trying to package it in nixpkgs so more
> > >>>> people can reproducibly use it without resorting to things like setup
> > >>>> scripts or Docker. Here are the cmake flags I'm using:
> > >>>>
> > >>>> https://github.com/NixOS/nixpkgs/pull/153014/files#diff-cb8d40a4e82c0c50ce6ec4031c12e06a4dac4bded86b9f01afcb2b4f22532dbbR46
> > >>>>
> > >>>>
> > >>>> Everything works including the system tests, which is a very good
> > >>>> sign. However, I'm having trouble with the unit tests that resembles
> > >>>> this problem:
> > >>>>
> > >>>> https://github.com/google/googletest/issues/2157
> > >>>>
> > >>>> Has anyone else run into this?
> > >>>>
> > >>>> Thanks!
> > >>>> Morgan
> > >>>>
> > >>>> _______________________________________________
> > >>>> klee-dev mailing list
> > >>>> klee-dev at imperial.ac.uk
> > >>>> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
> > >>>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> klee-dev mailing list
> > >>> klee-dev at imperial.ac.uk
> > >>> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
> > >>>
> > >>
> > >
> > >
> > > _______________________________________________
> > > klee-dev mailing list
> > > klee-dev at imperial.ac.uk
> > > https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
> >
> > _______________________________________________
> > klee-dev mailing list
> > klee-dev at imperial.ac.uk
> > https://mailman.ic.ac.uk/mailman/listinfo/klee-dev



More information about the klee-dev mailing list