| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
* handle BlockAddress (which is not a valid function pointer)
* there is no instruction with opcode 0
* add test for functionality
|
|
With version 3.5, LLVM introduced a subtle semantic change in the API of
`Value`. With that change, `use_begin()` is renamed to `user_begin()`.
Additionally, a new method `use_begin()` with a different meaning was
introduced. Now, `use_begin()` actually iterates over `Use`s, whereas
before, dereferencing it would give a `User *`. For further details,
please refer to https://reviews.llvm.org/rL203364.
Due to the reintroduction of `use_begin()`, existing code may still
compile, although the semantics have changed. In the code changed with
this patch, all `dyn_cast`s for `Use` fail and the else branch is
always taken.
|
|
LLVM commit eac309550f25 removed implicit iterator conversions. So we
have to get the iterators explicitly now.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
|
|
After LLVM commit 25569fdcdab0, archive iterator returns
object::Archive::Child instead of child_iterator, adapt to that.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
|
|
LLVM commit d912be98f8eb changed the prototype of linkModules to accept
std::unique_ptr. Adapt to that.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
|
|
createFunctionAttrsPass was split to createPostOrderFunctionAttrsPass
and createReversePostOrderFunctionAttrsPass in LLVM commit e96fb9ab15d4.
createGlobalsModRefPass was changed to createGlobalsAAWrapperPass in
LLVM commit 9146833fa313.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
|
|
Link intrinsic library before executing optimizations.
This makes sure that any optimization run by KLEE on the module
is executed for the intrinsic library as well.
Support .ll files as input for KLEE as well.
|
|
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
|
|
LLVM 3.7 added a PointeeType parameter to GetElementPtrInst::Create.
Let's handle that by a macro called KLEE_LLVM_GEP_TYPE, defined in
Version.h.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
|
|
|
|
This commit addresses the following:
* remove unused variables block_split (::runOnBasicBlock)
and LI (::IntrinsicCleanerPass) in IntrinsicCleanerPass
* add `dirty = true` to `Intrinsic::vacopy` case
* use `eraseFromParent()` methods instead of `removeFromParent()` and `delete`
* add `override` keyword to `runOn{Module,Function}` methods
|
|
version that takes an argument a stream
|
|
The behaviour couldn't be triggered for a kcachegrind from 2012.
|
|
|
|
|
|
llvm50 changed the semantics of SwitchInst::CaseIt and started using
"auto" variable type. So use it here too for all versions greater than
3.4 -- 3.4 does not support this semantics yet.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
|
|
configuration, TravisCI scripts and Dockerfile build appropriately.
There are a bunch of clean ups this enables but this commit doesn't
attempt them. We can do that in future commits.
|
|
|
|
Fixes klee/klee#717
delete on null pointer is always safe.
|
|
|
|
|
|
location as a string. Also added const qualifier to the printFileLine functions
|
|
Refactored some code related to constant evaluation
|
|
|
|
follow up of c9c90a0ecdce10172fd5318aea60a9ff4057679f
|
|
Request LLVM 3.4 as minimal requirement for KLEE
|
|
Implement basic support for vectorized instructions.
|
|
pass that checks these assertions. This improves several things.
* This pass provides more friendly messages than assertions in that it
just emits a warning and carries on checking the rest of the
instructions.
* The takes the checks outside of the Executor's hot path and so avoids
checking the same instruction multiple times. Now each instruction
is only checked once just before execution starts.
The disadvantage of this approach is the check for invariants we expect
to hold have been pulled far away from where we expect them to hold.
After discussion with @ccadar and @MartinNowack it was decided we will
take this hit to readability for better performance and simpler code in
the Executor.
|
|
We use LLVM's Scalarizer pass to remove most vectorized code so that the
Executor only needs to support the InsertElement and ExtractElement
instructions.
This pass was not available in LLVM 3.4 so to support that LLVM version
the pass has been back ported.
To check that the Executor is not receiving vector operand types
that it can't handle assertions have been added.
There are a few limitations to this implementation.
* The InsertElement and ExtractElement index cannot be symbolic.
* There is no support for LLVM < 3.4.
|
|
llvm: get rid of static_casts from iterators
|
|
- having an explicit function which is defined for multiple llvm
versions separately increases readability.
- also: error handling was simplified
- Personal motivation: being able to use this functionality in unit tests
fixes #561
related to #656
|
|
In LLVM 3.7, PassManager was moved to the legacy:: namespace. Introduce
a type for it and use it in the code.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
|
|
DILocation is not copyable in LLVM 3.7. So, pass it as reference and
make it const given we do not write to it.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
|
|
In commit b7a6aec4eeb4 (convert iterators using static_cast), I switched
all implicit casts to static_cast. It turned out that llvm 4.0 banned
casting via static_cast. See e.g. 1e2bc42eb988 in the llvm repo what
they do.
So similarly to the above commit, change all the casts of iterators to
"&*" which is what they do in LLVM.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
|
|
It became unnecessary when defining options and mainly undefined.
So introduce KLEE_LLVM_CL_VAL_END as suggested by @delcypher.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
|
|
Based on work by @ccadeptic23 and @delcypher.
Formatting fixed by @snf.
Fix compiler warning by @martijnthe.
Further fixes by @mchalupa.
Refactored, so that changes can be reviewed -- no massive changes in
whitespace and in the surrounding code.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
|
|
Module: simplify is_object checks
|
|
|
|
Newer versions of LLVM do not allow to implicitly cast iterators to
pointers where they point. So convert all such uses to explicit
static_cast, the same as LLVM code does.
Otherwise we see errors like:
lib/Core/Executor.cpp:548:15: error: no viable conversion from 'Module::iterator' (aka 'ilist_iterator<llvm::Function>') to 'llvm::Function *'
Function *f = i;
^ ~
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
|
|
object::Binary has isObject method, which can be used to check whether
it is an object::ObjectFile. Use that, since dyn_casting of
object::Binary is not allowed in newer LLVMs:
lib/Module/ModuleUtil.cpp:304:78: error: cannot convert ‘llvm::object::ObjectFile’ to ‘llvm::object::ObjectFile*’ in initialization
else if (object::ObjectFile *o = dyn_cast<object::ObjectFile>(child.get()))
^
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
|
|
It was marked as deprecated long time ago and finally removed in LLVM
3.9. Remove all uses of getGlobalContext and create our own context.
Propagate it all over the code then.
[v2] use ctx, not C as name
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
|
|
controlled by a new parameter `moduleIsFullyLinked`. When
true the linkage type of a weak alias is ignored. It is legal to do
this when the module is fully linked because there won't be another
function that could override the weak alias.
This fixes a previous assertion failure in `klee::getDirectCallTarget()`
triggered by the `test/regression/2016-11-24-bitcast-weak-alias.c` test case.
|
|
Reported by @jirislaby in #507.
|
|
This has shown that there is another circular dependency
(added by me! sigh...) between `kleeCore` and `kleeModule`.
|
|
|
|
transitive dependencies on KLEE's libraries rather than on the final
binaries. This is better because it means we can build
other tools that use KLEE's libraries and not need to express the
needed LLVM dependencies.
It also makes it clearer what the dependencies are between KLEE
libraries. This has illustrated a problem with the `kleeBasic`
library. It contains `ConstructSolverChain.cpp` which clearly
belongs in `kleaverSolver` not in `kleeBasic`. This will be fixed
later.
|
|
This is based off intial work by @jirislaby in #481. However it
has been substantially modified.
Notably it includes a separate build sytem to build the runtimes which
is inspired by the old build system. The reason for doing this is
because CMake is not well suited for building the runtime:
* CMake is configured to use the host compiler, not the bitcode
compiler. These are not the same thing.
* Building the runtime using `add_custom_command()` is flawed
because we can't automatically get transitive depencies (i.e.
header file dependencies) unless the CMake generator is makefiles.
(See `IMPLICIT_DEPENDS` of `add_custom_command()` in CMake).
So for now we have a very simple build system for building the runtimes.
In the future we can replace this with something more sophisticated if
we need it.
Support for all features of the old build system are implemented apart
from recording the git revision and showing it in the output of
`klee --help`.
Another notable change is the CMake build system works much better with
LLVM installs which don't ship with testing tools. The build system
will download the sources for `FileCheck` and `not` tools if the
corresponding binaries aren't available and will build them. However
`lit` (availabe via `pip install lit`) and GTest must already be
installed.
Apart from better support for testing a significant advantage of the
new CMake build system compared to the existing "Autoconf/Makefile"
build system is that it is **not** coupled to LLVM's build system
(unlike the existing build system). This means that LLVM's
autoconf/Makefiles don't need to be installed somewhere on the system.
Currently all tests pass.
Support has been implemented in TravisCI and the Dockerfile for
building with CMake.
The existing "Autoconf/Makefile" build system has been left intact
and so both build systems can coexist for a short while. We should
remove the old build system as soon as possible though because it
creates an unnecessary maintance burden.
|
|
|
