Summary: This patch allows libc++ to be built against the debug MSVC runtimes instead of just the release ones.
Reviewers: rnk, majnemer, compnerd, smeenai
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D28725
llvm-svn: 292006
Summary:
This patch attempts to clean up the macro configuration mess in `<__threading_support>`, specifically the mess involving external threading variants. Additionally this patch adds design documentation for `<__threading_support>` and the configuration macros it uses.
The primary change in this patch is separating the idea of an "external API" provided by `<__external_threading>` and the idea of having an external threading library. Now `_LIBCPP_HAS_THREAD_API_EXTERNAL` means that libc++ should use `<__external_threading>` and that the header is expected to exist. Additionally the new macro `_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL` is now used to configure for using an "external library" with the default threading API.
Reviewers: compnerd, rmaprath
Subscribers: smeenai, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28316
llvm-svn: 291275
This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:
- Building libc++ against a thread library other than pthreads.
- Building libc++ with an "external" thread API, allowing a separate library to
provide the implementation of that API.
The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.
For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.
Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.
When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).
Differential revision: https://reviews.llvm.org/D21968
Reviewers: bcraig, compnerd, EricWF, mclow.lists
llvm-svn: 281179
This patch updates the way libc++ handles checking for libatomic, in part
to prepare for https://reviews.llvm.org/D22073.
Changes:
* 'LIBCXX_HAS_ATOMIC_LIB' is now set whenever libatomic is available even libc++
doesn't need to manually link it.
* 'LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB' is now used to detect when libatomic
needs to be manually linked.
* 'LIBCXX_HAS_ATOMIC_LIB' now adds 'libatomic' as a available feature in the
test suite.
llvm-svn: 275759
Add the completed std::experimental::filesystem implementation and tests.
The implementation supports C++11 or newer.
The TS is built as part of 'libc++experimental.a'. Users of the TS need to
manually link this library. Building and testing the TS can be disabled using
the CMake option '-DLIBCXX_ENABLE_FILESYSTEM=OFF'.
Currently 'libc++experimental.a' is not installed by default. To turn on the
installation of the library use '-DLIBCXX_INSTALL_EXPERIMENTAL_LIBRARY=ON'.
llvm-svn: 273034
Summary:
Out-of-line symbols for <experimental/...> headers are not ABI or API stable and cannot live in the 'libc++.dylib'. Currently they have nowhere to live. I would like to add a new library target `libc++experimental.a` to fix this.
Previously I had suggested different libraries for different TS's (`libc++filesystem.a`, 'libc++LFTS.a`, ect). I no longer think this is the right approach.
Instead `c++experimental` will hold *all* TS implementations as a single monolithic library. I see two main benefits to this:
1. Users only have to know about and manually link one library.
2. It makes it easy to implement TS's with one or two out-of-line symbols. (Ex. PMRs)
`c++experimental` provides NO ABI compatibility. Symbols can freely be added/removed/changed without concern for ABI stability.
I will add documentation for this after landing this patch (but before adding anything to it).
`c++experimental` only builds as a static library. By default CMake will build/test this library but will *NOT* install it.
This patch adds the CMake and LIT logic needed to build/test the new library. Once this lands I plan on using it to implement parts of `<experimental/memory_resource>`.
Reviewers: mclow.lists
Subscribers: cfe-commits, theraven, krememek, dexonsmith, bcraig, beanz, danalbert
Differential Revision: http://reviews.llvm.org/D19856
llvm-svn: 268443
These changes make linking against static libraries more explicit. Instead
of using -lc++ and -lc++abi in the tests, an absolute path to the library is
provided instead.
The choices of shared vs. static, and the choices of library paths for both
libcxx and libcxxabi needed to be exchanged for this to work. In other words,
libcxx tests need to know the library path of libcxxabi, and whether libcxxabi
is a static or shared library.
Some Mac specific logic for testing against libc++abi had to be moved from
libcxxabi's config.py, as it was overriding choices made in libcxx's config.py.
That logic is now in libcxx's target_info.py.
Testing a static libcxx on Linux will now automatically link in librt most of
the time. Previously, lots of pthread tests would fail because of an
unresolved clock_gettime.
http://reviews.llvm.org/D16544
llvm-svn: 266730
This re-applies commit r260235. However, this time we add -gcc-toolchain
to the compiler's flags when the user has specified the LIBCXX_GCC_TOOLCHAIN
variable.
llvm-svn: 260515
This reverts commit r260235. It breaks LLVM's bootstrap when building
with a -gcc-toolchain and the system's gcc installation does not provide
the libatomic library and its headers. We should check whether
LIBCXX_GCC_TOOLCHAIN is set and adjust the flags accordingly.
llvm-svn: 260323
Summary:
This fixes the tests under std/atomics for 32-bit MIPS CPUs where the
8-byte atomic operations call into the libatomic library.
Reviewers: dsanders, mclow.lists, EricWF, jroelofs, joerg
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16613
llvm-svn: 260235
Summary:
This patch changes the tests to use the "__config_site" header if present instead of manually configuring for each option. This patch also removes the test flags for configuring some of these options. For example "lit -sv --param=enable_threads=OFF" no longer works. However lit will still correctly configure if the CMake option "-DLIBCXX_ENABLE_THREADS=OFF" is given at build time.
This patch will fix the libc++abi test configuration for `LIBCXX_ABI_VERSION` and `LIBCXX_ABI_UNSTABLE` one we teach it about 'project_obj_dir' . I would like to land this ASAP to prevent more work blockage.
Reviewers: mclow.lists, danalbert, eugenis, ed, jroelofs
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13714
llvm-svn: 250308
C++ macros and CMake options that specify the default ABI version of
the library, and can be overridden to pick up new ABI-changing
features.
llvm-svn: 250254
This patch adds the working parts of r243503. The difference with this patch
is that it doesn't include the HandleLLVMOptions.cmake file.
llvm-svn: 243698
This change was reverted in r243550 because it broke clang-format builds
(see PR24306).
This patch recommits a fixed version of the original.
llvm-svn: 243574
Summary:
This patch contains the following changes:
1. Require that libc++ can find a LLVM source directory. This is done the same way as `libc++abi` currently does.
2. Cleanup ugly configuration code in CMakeLists.txt by using `add_flags`, `add_flags_if`, and `add_flags_if_supported` macros.
The goals for this patch are:
1. Help libc++ be more consistent with how LLVM handles CMake options (see PR23670 PR23671).
2. Make it easier to use sanitizers using the `LLVM_USE_SANITIZER` option.
3. Make libc++'s CMakeLists.txt file easier to understand and change.
4. Move towards allowing libc++ to create Sphinx documentation (see http://efcs.ca/libcxx-docs).
5. Move towards allowing libc++ to use other LLVM utilities such as `not` and `FileCheck`.
Reviewers: mclow.lists, jroelofs, danalbert
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11308
llvm-svn: 243503
Summary: This patch adds special configuration logic to find the compiler_rt libraries required by sanitizers on OS X. The supported sanitizers are Address and Undefined.
Reviewers: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11381
llvm-svn: 242858
One of the aspects of CloudABI is that it aims to help you write code
that is thread-safe out of the box. This is very important if you want
to write libraries that are easy to reuse. For CloudABI we decided to
not provide the thread-unsafe functions. So far this is working out
pretty well, as thread-unsafety issues are detected really early on.
The following patch adds a knob to libc++,
_LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS, that can be set to disable
thread-unsafe functions that can easily be avoided in practice. The
following functions are not thread-safe:
- <clocale>: locale handles should be preferred over setlocale().
- <cstdlib>: mbrlen(), mbrtowc() and wcrtomb() should be preferred over
their non-restartable counterparts.
- <ctime>: asctime(), ctime(), gmtime() and localtime() are not
thread-safe. The first two are also deprecated by POSIX.
Differential Revision: http://reviews.llvm.org/D8703
Reviewed by: marshall
llvm-svn: 240527
The test cases were crashing due to the mixed usage of the unwinding
functions from both libunwind and libgcc_s. The unwind functions are
mixed because the "llvm_unwinder" entry is not available in the
lit.site.cfg for libc++. As a result, "-lgcc_s" is picked instead of
"-lunwind". The extra option to lit --param=link_flags="-lunwind" won't
help either.
This CL fix the problem by adding llvm_unwinder to lit.site.cfg.in.
llvm-svn: 237518
Summary:
This patch adds configuration to CMake and LIT for running the libc++ test-suite to generate code coverage.
To use code coverage use following instructions.
* Find the clang resource dir using `$CXX -print-search-dirs`. Let <library-dir> be the first library search directory.
* `cmake <regular-options> -DLIBCXX_GENERATE_COVERAGE=ON -DLIBCXX_COVERAGE_LIBRARY=<library-dir>/lib/<platform>/libclang_rt.profile.a <source>`
* `make cxx`
* `make check-libcxx`
* `make generate-libcxx-coverage`
The reason I want this patch upstreamed is so I can setup a bot that generates code coverage and posts in online for every revision.
Reviewers: mclow.lists, jroelofs, danalbert
Reviewed By: danalbert
Differential Revision: http://reviews.llvm.org/D8716
llvm-svn: 233669
The idea behind Nuxi CloudABI is that it is targeted at (but not limited to)
running networked services in a sandboxed environment. The model behind stdin,
stdout and stderr is strongly focused on interactive tools in a command shell.
CloudABI does not support the notion of stdin and stdout, as 'standard
input/output' does not apply to services. The concept of stderr does makes
sense though, as services do need some mechanism to log error messages in a
uniform way.
This patch extends libc++ in such a way that std::cin and std::cout and the
associated <cstdio>/<cwchar> functions can be disabled through the flags
_LIBCPP_HAS_NO_STDIN and _LIBCPP_HAS_NO_STDOUT, respectively. At the same time
it attempts to clean up src/iostream.cpp a bit. Instead of using a single array
of mbstate_t objects and hardcoding the array indices, it creates separate
objects that declared next to the iostream objects and their buffers. The code
is also restructured by interleaving the construction and setup of c* and wc*
objects. That way it is more obvious that this is done identically.
The c* and wc* objects already have separate unit tests. Make use of this fact
by adding XFAILs in case libcpp-has-no-std* is set. That way the tests work in
both directions. If stdin or stdout is disabled, these tests will therefore
test for the absence of c* and wc*.
Differential Revision: http://reviews.llvm.org/D8340
llvm-svn: 233275
Systems like FreeBSD's Capsicum and Nuxi CloudABI apply the concept of
capability-based security on the way processes can interact with the
filesystem API. It is no longer possible to interact with the VFS
through calls like open(), unlink(), rename(), etc. Instead, processes
are only allowed to interact with files and directories to which they
have been granted access. The *at() functions can be used for this
purpose.
This change adds a new config switch called
_LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE. If set, all functionality
that requires the global filesystem namespace will be disabled. More
concretely:
- fstream's open() function will be removed.
- cstdio will no longer pull in fopen(), rename(), etc.
- The test suite's get_temp_file_name() will be removed. This will cause
all tests that use the global filesystem namespace to break, but will
at least make all the other tests run (as get_temp_file_name will not
build anyway).
It is important to mention that this change will make fstream rather
useless on those systems for now. Still, I'd rather not have fstream
disabled entirely, as it is of course possible to come up with an
extension for fstream that would allow access to local filesystem
namespaces (e.g., by adding an openat() member function).
Differential revision: http://reviews.llvm.org/D8194
Reviewed by: jroelofs (thanks!)
llvm-svn: 232049
Executors can be specified at configure time by using the -DLIBCXX_EXECUTOR=""
option. Examples include:
$ cmake <other_flags> -DLIBCXX_EXECUTOR="TimeoutExecutor(30,LocalExecutor())"
This runs individual tests with a maximum duration
$ cmake <other_flags> -DLIBCXX_EXECUTOR="SSHExecutor('hostname','username')"
This runs tests on a remote target, using scp to shuttle binaries to the
target, and ssh to invoke commands there.
$ cmake <other_flags> -DLIBCXX_EXECUTOR="PrefixExecutor('/path/to/run/script',LocalExecutor())"
This assumes the script knows how to copy run the executables passed to it,
and allows for the ultimate control. This is useful for running things
inside emulators like Valgrind & QEMU.
TODO: This doesn't claim to support ShTest tests yet, that will take a bit more
thought & finagling (I'm still not sure how to orchestrate copy-in for those cases.
I've also punted on what to do about tests that read data files. The testsuite
has several tests that need to read *.dat files placed next to them, and
currently those aren't copied over when using, say, an SSHExecutor. The
affected tests are:
libc++ :: std/input.output/file.streams/fstreams/filebuf.virtuals/pbackfail.pass.cpp
libc++ :: std/input.output/file.streams/fstreams/filebuf.virtuals/underflow.pass.cpp
libc++ :: std/input.output/file.streams/fstreams/ifstream.assign/member_swap.pass.cpp
libc++ :: std/input.output/file.streams/fstreams/ifstream.assign/move_assign.pass.cpp
libc++ :: std/input.output/file.streams/fstreams/ifstream.assign/nonmember_swap.pass.cpp
libc++ :: std/input.output/file.streams/fstreams/ifstream.cons/move.pass.cpp
libc++ :: std/input.output/file.streams/fstreams/ifstream.cons/pointer.pass.cpp
libc++ :: std/input.output/file.streams/fstreams/ifstream.cons/string.pass.cpp
libc++ :: std/input.output/file.streams/fstreams/ifstream.members/close.pass.cpp
libc++ :: std/input.output/file.streams/fstreams/ifstream.members/open_pointer.pass.cpp
libc++ :: std/input.output/file.streams/fstreams/ifstream.members/open_string.pass.cpp
libc++ :: std/input.output/file.streams/fstreams/ifstream.members/rdbuf.pass.cpp
libc++ :: std/localization/locales/locale.convenience/conversions/conversions.buffer/pbackfail.pass.cpp
libc++ :: std/localization/locales/locale.convenience/conversions/conversions.buffer/underflow.pass.cpp
Note: One thing to watch out for when using the SSHExecutor for cross-testing is
that you'll also want to specify a TargetInfo object (so that the host's
features aren't used for available-features checks and flags setup).
http://reviews.llvm.org/D7380
llvm-svn: 230592
When the remote execution patch lands, this will allow us to drop in a
replacement TargetInfo object for locale support discovery, alleviating
the assumption that host==target.
http://reviews.llvm.org/D7601
llvm-svn: 229111
Summary:
In order to fully replace the testit script we need to update LIT so it provides the same functionality.
This patch adds a number of different configuration options to LIT to do that. It also adds documentation for all of the command line parameters that LIT supports.
Generic options added:
- `libcxx_headers`
- `libcxx_library`
- `compile_flags`
Generic options modified:
- `link_flags`: Changed from overriding the default args to adding extra args instead (to match compile flags)
- `use_sanitizer`: Renamed from `llvm_use_sanitizer`
Please see the added documentation for more information about the switches. As for the actual documentation I'm not sure if it should be kept in libc++ forever since it adds an undue maintenance burden, but I think it should be added for the time being while the changes are new. I'm verify unskilled with HTML so if the documentation needs any changes please let me know.
Hopefully this will kill testit.
Reviewers: jroelofs, mclow.lists, danalbert
Reviewed By: danalbert
Subscribers: alexfh, cfe-commits
Differential Revision: http://reviews.llvm.org/D5877
llvm-svn: 224728
Summary:
Currently to run tests in tree you need to symlink the lit.site.cfg file generated by the cmake build into the source tree, and teach your VCS to ignore it.
This allows the user to specify where to find the lit.site.cfg file two different ways:
* lit_site_config lit parameter
* LIT_SITE_CONFIG enviroment variable.
example usage:
```
lit -sv --param=libcxx_site_config=path/to/libcxx-build/test/lit.site.cfg path/to/tests
```
Or
```
export LIBCXX_SITE_CONFIG=path/to/libcxx-build/test/lit.site.cfg
lit -sv path/to/tests
```
The command line parameter will override the environment variable.
If neither options are present a warning is issued and the `lit.cfg` file is loaded directly.
Reviewers: mclow.lists, jroelofs, danalbert
Reviewed By: danalbert
Subscribers: ddunbar, cfe-commits
Differential Revision: http://reviews.llvm.org/D6255
llvm-svn: 224671
Currently hacks must be used in to configure and build libc++ without threads
when using CMake. This patch adds CMake options to enable/disable building with
threads and a monotonic clock.
This patch also propagates the configuration information to lit so the tests
are properly configured as well.
llvm-svn: 223591
Summary:
This is the second attempt at allowing for the use of libraries that the linker cannot find. The first attempt used `CMAKE_LIBRARY_PATH` and `find_library` to select which ABI library should be used. There were a number of problems with this approach:
- `find_library` didn't work with cmake targets (ie in-tree libcxxabi build)
- It wasn't always possible to determine where `find_library` actually found your library.
- `target_link_libraries` inserted the path of the ABI library into libc++'s RPATH when `find_library` was used.
- Linking libc++ and it's ABI library is a special case. It's a lot easier to keep it simple.
After discussion with @cbergstrum a new approach was decided upon.
This patch achieve the same ends by simply using `LIBCXX_CXX_ABI_LIBRARY_PATH` to specify where to find the library (if the linker won't find it). When this variable is defined it is simply added as a library search path when linking libc++. It is a lot easier to duplicate this behavior in LIT. It also prevents libc++ from being linked with an RPATH.
Reviewers: mclow.lists, cbergstrom, chandlerc, danalbert
Reviewed By: chandlerc, danalbert
Subscribers: chandlerc, cfe-commits
Differential Revision: http://reviews.llvm.org/D5860
llvm-svn: 220157
Summary:
This patch adds support for building/testing libc++ with an ABI library that the linker would not normally find.
- `CMAKE_LIBRARY_PATH` is used to specify the list of search directories.
- The ABI library is now found using `find_library` instead of assuming its along the linker's search path.
- `CMAKE_LIBRARY_PATH` is passed to our LIT config as `library_paths`.
- For each path in `library_paths` the following flags are added `-L<path> -Wl,-rpath -Wl,<path>`
Some changes in existing behavior were also added:
- `target_link_libraries` is now passed the ABI library file instead of the library name. Ex `target_link_libraries(cxx "/usr/lib/libc++abi.so")` vs `target_link_libraries(cxx "c++abi")`.
- `-Wl,-rpath -Wl,<path>` is now used on OSX to link to libc++ instead of env['DYLD_LIBRARY_PATH'] if `use_system_lib=False`.
Reviewers: mclow.lists, danalbert, EricWF
Reviewed By: EricWF
Subscribers: emaste, cfe-commits
Differential Revision: http://reviews.llvm.org/D5038
llvm-svn: 220118
Summary:
This patch adds support for LLVM_USE_SANITIZER when being built in-tree and standalone.
This patch does the following things:
1. define the LLVM_USE_SANITIZER option to "" when being built standalone. This also helps show we support it.
2. Translate LLVM_USE_SANITIZER when standalone in a very similar way done in llvm/cmake/HandleLLVMOptions.cmake.
3. Add config.llvm_use_sanitizer to lit.site.cfg.in
4. Add code to translate config.llvm_use_sanitizer's value into the needed compile flags in lit.cfg.
Currently lit.cfg assumes that that the compiler supports '-fno-omit-frame-pointer' while CMakeLists.txt actually checks to see if its supported. We could pass this information to lit but I'm not sure its needed.
Reviewers: mclow.lists, danalbert
Reviewed By: danalbert
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4949
llvm-svn: 215872
Summary:
This patch does two things:
CMake Update:
- Add compiler flag checks for -std=c++11 and -std=c++1y and remove check for -std=c++0x.
- Add configuration option LIBCXX_ENABLE_CXX1Y to prevent/allow -std=c++1y from being chosen as the std version. LIBCXX_ENABLE_CXX1Y is set to OFF by default.
- if LIBCXX_ENABLE_CXX1Y is enabled then set LIBCXX_STD_VERSION to c++1y and fail if the compiler does not support -std=c++1y
- If c++1y is not enabled then use c++11 and fail if the compiler does not support c++11.
Lit Update:
- Update lit.site.cfg.in to capture LIBCXX_STD_VERSION information as config.std.
- Remove mentions of has_cxx0X configuration option.
- Check for `--param std=X' passed to lit on the command line.
- Choose the std for the tests either from command line parameter or (if it doesn't exist) the lit.site.cfg.
Reviewers: mclow.lists, danalbert
Reviewed By: danalbert
Subscribers: emaste, rnk, ajwong, danalbert, cfe-commits
Differential Revision: http://reviews.llvm.org/D4329
llvm-svn: 215802
Linking against libstdc++, rather than libsupc++, is probably better
for people who need to link against clients of libstdc++. Because
libsupc++ is provided only as a static library, its globals are not
shared between the static library and the copy linked into libstdc++.
This has been found to cause at least one test failure.
This also removes a number of symbols which were multiply defined
between libstdc++ and libc++, only when linking with libstdc++.
Differential Revision: http://llvm-reviews.chandlerc.com/D1825
llvm-svn: 192075
Eric Fiselier