- C++ 75%
- SMT 13.4%
- CMake 3.5%
- Yacc 3%
- C 1.6%
- Other 3.4%
The signed division family had no interval transfer functions (a TODO): every SBVDIV, SBVREM and SBVMOD node yielded the complete range. Now, for widths up to 64, the operands split at the sign boundary into sign-consistent boxes described by magnitude ranges. Within a box the quotient magnitude is monotone in both arguments, so its corners give exact per-box bounds; remainder magnitudes are bounded by the divisor and dividend magnitudes, and are exact for a constant-magnitude divisor when the dividend magnitudes share a quotient. A possibly-zero divisor contributes the division-by-zero values. The result is the unsigned hull of the pieces. Ground truth in the tests below is STP's own constant evaluator, so the signed semantics, including division by zero, are exactly the solver's. Exhaustively at widths 3 and 4: sbvdiv is 100% exact; sbvrem 93%/90%; sbvmod 84%/82%; zero unsoundness. On 10,000 random 64-bit cases per operator, 6,849 / 4,644 / 3,995 results are strictly tighter than the old complete range, with zero regressions or contradictions and zero evaluator-checked witness violations. Two byte-identical rewrites ride along (verified on 60,000 dumped results): - BVSGT: the recursive pole-split with per-segment bitvector allocations becomes two chunk-wise signed comparisons of the attained signed extremes; an interval crossing the sign boundary attains both of its width's type extremes. 3,397 -> 2,940 ns/call at 64 bits, and still exhaustively exact. - BVDIV/BVMOD take word fast paths at widths up to 64: hardware divisions instead of BitVector_Div_Pos. bvdiv 4,959 -> 2,994 ns/call, the last interval propagator that sat above the dispatch floor. All 54 ctest suites pass. |
||
|---|---|---|
| .github/workflows | ||
| bindings | ||
| cmake | ||
| data | ||
| docs | ||
| examples/simple | ||
| include/stp | ||
| lib | ||
| papers | ||
| scripts | ||
| tests | ||
| tools | ||
| utils | ||
| windows | ||
| .clang-format | ||
| .dockerignore | ||
| .gitignore | ||
| .gitmodules | ||
| appveyor.yml | ||
| AUTHORS | ||
| CMakeLists.txt | ||
| Docker.ubuntu20 | ||
| Dockerfile | ||
| LICENSE | ||
| LICENSE_COMPONENTS | ||
| README.markdown | ||
| STPConfig.cmake.in | ||
| STPConfigVersion.cmake.in | ||
STP
STP is a constraint solver (or SMT solver) aimed at solving constraints of bitvectors and arrays. These types of constraints can be generated by program analysis tools, theorem provers, automated bug finders, cryptographic attack tools, intelligent fuzzers, model checkers, and by many other applications.
- Homepage: https://stp.github.io/
- Ubuntu PPA: https://launchpad.net/~simple-theorem-prover/+archive/ubuntu/ppa/+packages
- Docker image:
docker pull msoos/stp
Build and install
For a quick install:
sudo apt-get install git cmake bison flex libboost-all-dev libgmp-dev python2 perl
git clone https://github.com/stp/stp
cd stp
git submodule init && git submodule update
./scripts/deps/setup-gtest.sh
./scripts/deps/setup-outputcheck.sh
./scripts/deps/setup-cms.sh
./scripts/deps/setup-minisat.sh
mkdir build
cd build
cmake ..
cmake --build .
sudo cmake --install .
Or, using Homebrew:
brew install stp
For more detailed instructions, see towards the end of the page.
Input format
The SMT-LIB2 format is the recommended file format, because it is parsed by all modern bitvector solvers. Only quantifier-free bitvectors and arrays are implemented from the SMT-LIB2 format.
Usage
Run with an SMT-LIB2 file:
stp myproblem.smt2
Overflowing a 32-bit integer using the python interface:
import stp
In [1]: import stp
In [2]: a = stp.Solver()
In [3]: x = a.bitvec('x')
In [4]: y = a.bitvec('y')
In [5]: a.add(x + y < 20)
In [6]: a.add(x > 10)
In [7]: a.add(y > 10)
In [8]: a.check()
Out[8]: True
In [9]: a.model()
Out[9]: {'x': 4294967287L, 'y': 11L}
With Docker:
docker pull msoos/stp
echo "(set-logic QF_BV)
(assert (= (bvsdiv (_ bv3 2) (_ bv2 2)) (_ bv0 2)))
(check-sat)
(exit)" | docker run --rm -i msoos/stp
Architecture
The system performs word-level preprocessing followed by translation to SAT which is then solved by a SAT solver. In particular, we introduce several new heuristics for the preprocessing step, including abstraction-refinement in the context of arrays, a new bitvector linear arithmetic equation solver, and some interesting simplifications. These heuristics help us achieve several magnitudes of order performance over other tools, and also over straight-forward translation to SAT. STP has been heavily tested on thousands of examples sourced from various real-world applications such as program analysis and bug-finding tools like EXE, and equivalence checking tools and theorem-provers.
Detailed Building and Installation
STP is built with CMake, version 3.0.2 or newer. CMake is a meta build system that generates build files for other tools such as make(1), Visual Studio, Xcode, etc.
Configuration variables
Here are a few interesting configuration variables. These apply to all generators.
CMAKE_BUILD_TYPE- The build type (e.g. Release)CMAKE_INSTALL_PREFIX- The prefix for install (e.g. /usr/local )ENABLE_ASSERTIONS- If TRUE STP will be built with asserts.ENABLE_TESTING- Enable running testsENABLE_PYTHON_INTERFACE- Enable building the Python interfacePYTHON_EXECUTABLE- Set python executable in case you have more than one python installedSANITIZE- Use Clang's sanitization checksSTATICCOMPILE- Build static libraries and binaries instead of dynamic
Dependencies
STP relies on : boost, flex, bison and minisat. You can install these by:
$ sudo apt-get install cmake bison flex libboost-all-dev python perl minisat
If your distribution does not come with minisat, STP maintains an updated fork. It can be built as follows:
$ git clone https://github.com/stp/minisat
$ cd minisat
$ mkdir build && cd build
$ cmake ..
$ cmake --build .
$ sudo cmake --install .
$ command -v ldconfig && sudo ldconfig
STP uses minisat as its SAT solver by default but it also supports other SAT solvers including CryptoMiniSat as an optional extra. If installed, it will be detected during the cmake and used:
$ git clone https://github.com/msoos/cryptominisat
$ cd cryptominisat
$ mkdir build && cd build
$ cmake ..
$ cmake --build .
$ sudo cmake --install .
$ command -v ldconfig && sudo ldconfig
Alternatively, these commands are pre-configused in scripts/deps/setup-minisat.sh and scripts/deps/setup-cms.sh (respectively).
Building against non-installed libraries
If you wish to build STP's dependencies without installing them, you can tell CMake where to find the non-installed artefacts. For example:
-DMINISAT_INCLUDE_DIRS:PATH=<path>and-DMINISAT_LIBDIR:PATH=<path>-- the paths tominisat/core/Solver.hand theminisatlibraries (respectively)-Dcryptominisat5_DIR:PATH=<path>-- the path tocryptominisat5Config.cmake
If you did not install these development libraries, then MINISAT_LIBDIR can be set to your build folder for minisat and cryptominisat5_DIR to your build folder for CryptoMiniSat.
Building a static library and binary
$ mkdir build && cd build
$ cmake -DSTATICCOMPILE=ON ..
$ cmake --build .
$ sudo cmake --install .
$ command -v ldconfig && sudo ldconfig
Configuration and build options
To tweak the build configuration:
-
Run
cmake-gui /path/to/stp/source/rootinstead ofcmake. This user interface lets you control the value of various configuration variables and lets you pick the build system generator. -
Run
ccmakeinstead ofcmake. This provides an ncurses terminal interface for changing configuration variables. -
Pass
-D<VARIABLE>=<VALUE>options tocmake(not very user friendly). It is probably best if you only configure this way if you are writing scripts.
You can also tweak configuration later by running make edit_cache and edit any configuration variables, reconfigure and then regenerate the build system. After configuration, build by running make.
You can use the -j<n> flag to significantly to decrease build time by running <n> jobs in parallel (e.g. make -j4).
Testing
git clone https://github.com/stp/stp
git submodule update --init
pip install lit
mkdir build
cd build
cmake -DENABLE_TESTING=ON ..
make
make test
Installing
To install run make install and to uninstall run make uninstall. The root of installation is controlled by the CMAKE_INSTALL_PREFIX variable at configure time. You can change this by running make edit_cache and editing the value of CMAKE_INSTALL_PREFIX.
Building on Windows/Visual Studio
You will need to install cmake and follow the steps that AppVeyor follows. In case you need the static binary, you can always access it as a binary artifact at the AppVeyor build page. In case you still have trouble, please see the mini-HOWTO at issue #319.
Building Docker
git clone https://github.com/stp/stp
cd stp
docker build -t stp .
echo "(set-logic QF_BV)
(assert (= (bvsdiv (_ bv3 2) (_ bv2 2)) (_ bv0 2)))
(check-sat)
(exit)" | docker run --rm -i stp
Authors
- Vijay Ganesh
- Trevor Hansen
- Mate Soos
- Dan Liew
- Ryan Govostes
- Andrew V. Jones
- And many others...