Age | Commit message (Collapse) | Author |
|
|
|
iostream injects static constructor function into every compilation unit.
Remove this to avoid it.
|
|
According to LLVM: lightweight and simpler implementation of streams.
|
|
This now corresponds to the sorts of the operations we emit, as far as I
can tell.
Read is one example of an operation that now works correctly (with 1-bit
array ranges).
It's also possible (but not very useful, and I don't think KLEE can
produce it) for other operations such as Add to operate on 1-bit values,
and this patch also fixes those.
|
|
|
|
MetaSMTBuilder.
|
|
Fix handling of memory usage in KLEE.
|
|
clang warning.
|
|
warning.
|
|
|
|
not using glibc the malloc usage if computed differently.
|
|
Memory usage API in LLVM since 3.3 is not working the way it is
intended by KLEE. This ports the pre 3.3. version to KLEE.
Fixes the malloc test case.
|
|
lists can have NULL roots, e.g. in MemoryObject instances with concrete
contents, where root is allocated lazily only when the updates are required).
Also checking whether array updates are typed correctly in UpdateList::extend()
rather than in the constructor of UpdateNode (only for update lists with
non-NULL roots).
|
|
|
|
|
|
instead it was reporting real user ID of the process.
|
|
has been removed in LLVM3.4
|
|
it has been removed. From the LLVM 3.4 release notes:
"
The library call simplification pass has been removed. Its functionality
has been integrated into the instruction combiner and function attribute
marking passes.
"
|
|
of old V1 path API.
LLVM2.9 supports LLVM's V2 path API. Because that is the minimum
version we support we should just use this API everywhere so we
reduce the number of #if LLVM_VERSION_CODE macros and duplicated
code.
|
|
|
|
Old Path API was removed
|
|
This change makes it possible to more reliably write unit tests which check
that an expression is equivalent to an expected pretty printed string.
|
|
(alphabetical) order.
|
|
|
|
|
|
that is the samw width of the "expr" expression.
It probably is the same width (it defintely is in SMT-LIB but I'm not
sure about STP) but it is probably better to be explicit.
|
|
|
|
overshifts to zero. Test case is included.
|
|
to zero. Test case is included.
|
|
overshifts to zero. Test case is included.
|
|
to zero. Test case is included.
|
|
zero. A test case was added for this.
In addition the use to vc_bvExtract() was removed for shifting left by an
expression because we don't want/need bitmasked behaviour anymore.
|
|
a bug in the previous commit where 32-bit width was assumed.
|
|
The other shift operators still need to be changed
|
|
of modules left because this information is no longer correct
(we no longer shrink the vector).
|
|
then clean up is performed.
|
|
because "RemovedSymbols" implies that the symbols have already been
removed which is misleading because we don't remove until the end.
|
|
|
|
Iterators get invalidated after elements of std::vector/set are
deleted. Avoid this by remembering which elements need to be
deleted and do it after iterating over the data structure.
|
|
KLEE intrinsics as undefined symbols
|
|
that clients can access HandlerInfo nicely.
|
|
bitcode archive linker.
|
|
LLVM >= 3.3 by effectively reimplementing the linking algorithm
used in LLVM <= 3.2.
The LLVM specific bitcode archive format has been removed
from LLVM >= 3.3 . Now archives are normal system archives that can
contain LLVM bitcode modules as well as regular binary object files.
The previous commit implemented an approach where ALL the bitcode
modules get linked in which can be terribly slow when klee-uclibc gets
linked (~600 LLVM modules).
Here are the options that I considered to address this:
* Use LD with LLVM gold plug-in and call as an external program.
I Don't really want to add another dependency to KLEE. It already
has enough!
* Use the upcomming LLVM linker (lld). Not really an option
because at the time of writing there is no support for linking
archives of bitcode modules.
* Don't use archives at all and just work with modules (i.e.
replace uses of llvm-ar with llvm-link and tinker with the
flags a little). This isn't so great because the resulting
LLVM bitcode module we execute is bigger than it should be.
* Reimpelent bitcode archive linking ourselves in a slightly
better way.
I've gone for the last option
This implementation unfortunately loads all bitcode modules into memory
first so we can query the module symbols tables. I would prefer to read
the archive's index and link in modules on demand but unfortunately
although the new Object::Archive interface in LLVM allows iteration over
symbols it doesn't provide a way of knowing if that symbol is
defined/undefined.
This implementation is far from perfect!
|
|
With LLVM 3.3 the linker does not support reading of
archive files directly. This brings the support back
(based on llvm-mn).
Furthermore, linking single bc files or archives with
bc and object files mixed is supported as well.
|
|
In case linking of external libraries failed, user would
only be informed if KLEE is compiled with assertions enabled.
This fix lets KLEE always fail.
|
|
Existence of main() function is checked with assertion.
This check fails if KLEE is compiled in Release mode.
|
|
Feature klee internal functions
|
|
|
|
emphasising that the function cannot be returned from early.
|
|
file as well.
|