| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
directory. This improves the organization of the code, and also makes it easier to reuse Expr outside KLEE.
|
|
|
|
and "default=off" in --help
|
|
MemoryManager.cpp
|
|
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
|
|
|
|
Allows to provide 0 as an address to allocate deterministic memory
area at any free space.
|
|
|
|
Deterministic allocation provides an internal allocator which
mmaps memory to a fixed static address.
This way, same allocation is assured across different KLEE runs
for the same application assuming a deterministic searcher.
In addition, this patch provides following options:
-allocate-determ: switch on/off deterministic allocation
-allocate-determ-size: adjust preallocated memory
-null-on-zero-malloc: returns null pointer in case a malloc
of size 0 was requested. According to standard, also a non-null pointer
can be returned (which happens with the default glibc malloc implementation)
-allocation-space: space between allocations can be adjusted. KLEE is not able
to detect out-of-bound accesses which are inside another but wrong object.
Due the implementation of typical allocators adjacent mallocs have space
in between for management purposes. This spaces helped KLEE to detect off-by-1/2 accesses.
For higher numbers, the allocation space has to be increased.
-allocate-determ-start-address: adjust deterministic start address. The addres
has to be page aligned. KLEE fails if it cannot acquire this address
|
|
For vararg handling, arguments of size bigger than 64 bit need
to be handled 128bit aligned according to AMD calling conventions
AMD64-ABI 3.5.7p5.
To handle that case correctly, we do:
1) make sure that every argument is aligned correctly in
an allocation for function arguments
2) the allocation itself is aligned correctly
|
|
Support directory
|
|
Addresses the issue raised by Bowen Zhou at http://keeda.stanford.edu/pipermail/klee-dev/2012-November/000972.html.
Fixed test case that depended on the old behavior.
git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@168797 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
leak in KLEE.
From Gang Hu: "The memory leak is caused by two reasons. First, the
MemoryObject objects are not freed, until the MemoryManager is
destroyed. Second, when KLEE allocates a non-fixed MemoryObject
object, KLEE also allocates a block of memory which is the same as the
object's size. This block of memory is never freed. So, this patch
generally does reference counting on the MemoryObject objects, and
frees them as soon as the reference count drops to zero."
Many thanks to Paul Marinescu as well, who tested this patch
thoroughly on the Coreutils benchmarks. On 1h runs, the memory
consumption typically goes down by 1-5%, but some applications which
see more significant gains.
git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@148402 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to klee_error() to make sure the check is done even when assertions
are disabled. This makes the AsmAddresses test pass with assertions
disabled.
git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@130067 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
64-bit addresses).
git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@73327 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
asserts.
git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@72924 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Lots more tweaks, documentation, and web page content is needed,
but this should compile & work on OS X & Linux.
git-svn-id: https://llvm.org/svn/llvm-project/klee/trunk@72205 91177308-0d34-0410-b5e6-96231b3b80d8
|
