Age | Commit message (Collapse) | Author |
|
|
|
`libc++` include headers are now split between platform dependent and
platform independent code.
Before, only include files for the platform independent code were
considered. Add support to automatically find platform dependent
includes as well.
Simplify the detection of libraries and paths.
Instead of pointing to the `v1` directory, pointing to the include
directory for `-DKLEE_LIBCXX_INCLUDE_PATH` is enough.
Update build script to support this as well.
|
|
permission error a single time in symbolic execution mode.
The rewrite also fixes a bug reported in #1230.
Rewrote the FilePerm.c test accordingly.
|
|
This variable was introduced by d2f5906da4ae37a41ae257e5308d50e19689877b
but not included in `config.h` before. As a result `#ifdef` would always
fail. Moving the code is necessary to set the variable before `config.h`
is created using `configure_file()` in CMakeLists.txt.
|
|
|
|
|
|
|
|
Former build system provided additional flags for building bitcode while
they were not required, e.g. under BSD or MacOS.
|
|
LLVM became more complex, use LLVM's CMake functionality directly instead
of replicating this behaviour in KLEE's build system.
Use the correct build flags provided by LLVM itself.
This is influenced by the way LLVM is built in the first place.
Remove older CMake support (< 3.0).
|
|
standard, characters should be compared as unsigned chars.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
macOS versions, where stat64 is not defined anymore.
|
|
|
|
|
|
|
|
|
|
commit 8ed005daf0ab of glibc-2.33 (Remove stat wrapper functions, move
them to exported symbols) removed renames of `__fxstat`, `__xstat`, and
`__lxstat` to `__fxstat64`, `__xstat64`, and `__lxstat64`, respectively.
But we relied on the renames to build `fd_64.c` properly. With glibc
2.33, we now see link failures of the POSIX runtime:
error: Linking globals named '__xstat': symbol multiply defined!
Rename the functions using `__REDIRECT_NTH` in the code as
`__USE_FILE_OFFSET64` case (which we define at the top of the file by
`#define _FILE_OFFSET_BITS 64`) did exactly that.
Fixes #1384.
|
|
* failing malloc was not handled before, now returns null/ENOMEM
* when path is non-null and size is zero return null/EINVAL
|
|
|
|
|
|
- `-DNDebug` -> `-DNDEBUG`
- different flags for `Release{+Debug,}+Asserts`
- `-g` is no longer part of common flags
- `-D_DEBUG` is now only set for debug builds
- removed unused `LIB_BC_FLAGS_{32,64}`
- added example, architecture prefix for specific flags
|
|
Automatically detect if 32bit bitcode files can be built.
In this case, build runtime library with 32bit as well.
|
|
|
|
used.
|
|
|
|
compile it with -D_FORTIFY_SOURCE=0 to avoid infinite recursion.
|
|
|
|
|
|
Every runtime library can be build with multiple configurations.
Replace the Makefile-based setup by cmake one.
Currently, we generate 32bit and 64bit libraries simultaneously and can link against them.
|
|
This was executing the loop when n==0 leading to an out of bound pointer
error.
Found while verifying Rust code that compares strings.
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Felix Rath <felix.rath@comsys.rwth-aachen.de>
|
|
We implement the Itanium ABI unwinding base-API, and leave the
C++-specific parts to libcxxabi.
Co-authored-by: Lukas Wölfer <lukas.woelfer@rwth-aachen.de>
|
|
|
|
with a test case.
|
|
This is a thread-local version of __cxa_atexit (but, in the absence
of threads, it is sufficient to just call __cxa_atexit).
The test is based on the existing test for atexit in
test/Runtime/Uclibc/2008-03-04-libc-atexit-uses-dso-handle.c
The motivation for adding this function is to support the Rust standard
library that calls __cxa_thread_atexit_impl.
This function is usually a weak symbol but, in KLEE, this behaves like a call
to an unknown function and chaos ensues.
Worse, it happens just as the program is cleanly shutting itself down,
so programs that are cleanly exiting crash with the wrong message.
|
|
This instrinsic detects whether the program is being executed
symbolically or concretely (i.e., using the libkleeRuntest library).
The intended usage (illustrated in the test program) is to
allow the test program to display the input values by invoking
any libraries it wants to.
This is especially valuable if you are constructing complex,
structured values and for languages like Rust (or C++) that have
rich libraries and print libraries.
For example, you might pick a symbolic value N with the
assumption "0 <= N < 10" and then pick N symbolic
values and write them to an array.
The resulting ktest file is a bit hard to understand compared with the
output of the standard print function in Rust/C++.
|
|
|
|
|