Instead of using TARGET_TRIPLE, which is always set to LLVM_DEFAULT_TARGET_TRIPLE,
use that variable directly to populate the various XXXX_TARGET_TRIPLE
variables in the runtimes.
This re-applies 77396bbc98 and 5099e01568, which were reverted in
850b57c5fb because they broke the build.
Differential Revision: https://reviews.llvm.org/D106009
This configuration is interesting because GCC has a different level of
strictness for some C++ rules. In particular, it implements the older
standards more stringently than Clang, which can help find places where
we are non-conforming (especially in the test suite).
Differential Revision: https://reviews.llvm.org/D105936
When a target triple is specified in CMake via XXX_TARGET_TRIPLE, we tried
passing the --target=<...> flag to the compiler. However, not all compilers
support that flag (e.g. GCC, which is not a cross-compiler). As a result,
setting e.g. LIBCXX_TARGET_TRIPLE=<host-triple> would end up trying to
pass --target=<host-triple> to GCC, which breaks everything because the
flag isn't even supported.
This commit only adds `--target=<...>` & friends to the flags if it is
supported by the compiler.
One could argue that it's confusing to pass LIBCXX_TARGET_TRIPLE=<...>
and have it be ignored. That's correct, and one possibility would be
to assert that the requested triple is the same as the host triple when
we know the compiler is unable to cross-compile. However, note that this
is a pre-existing issue (setting the TARGET_TRIPLE variable never had an
influence on the flags passed to the compiler), and also fixing that is
starting to look like reimplementing a lot of CMake logic that is already
handled with CMAKE_CXX_COMPILER_TARGET.
Differential Revision: https://reviews.llvm.org/D106082
The feature was always defined, which means that the two test cases
guarded by it were never run.
Differential Revision: https://reviews.llvm.org/D106062
add_lit_testsuite() takes Lit parameters passed to it and adds them
to the parameters used globally when running all test suites. That
means that a target like `check-all`, which ends up calling Lit on
the whole monorepo, will see the test parameters for all the individual
project's test suites.
So, for example, it would see `--param std=c++03` (from libc++abi), and
`--param std=c++03` (from libc++), and `--param whatever` (from another
project being tested at the same time). While always unclean, that works
when the parameters all agree. However, if the parameters share the same
name but have different values, only one of those two values will be used
and it will be incredibly confusing to understand why one of the test
suites is being run with the incorrect parameter value.
For that reason, this commit moves away from using add_lit_testsuite()'s
PARAM functionality, and serializes the parameter values for the runtimes
in the generated config.py file instead, which is local to the specific
test suite.
Differential Revision: https://reviews.llvm.org/D105991
This commit reverts 5099e01568 and 77396bbc98, which broke the build
in various ways. I'm reverting until I can investigate, since that
change appears to be way more subtle than it seemed.
This is a second attempt at D101497, which landed as
9a9bc76c0e but had to be reverted in
8cf7ddbdd4.
This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is
empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to
"/bin" not "bin" as intended and as was originally.
One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty,
defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach.
But, I think it is more ergonomic to allow those project-specific paths
to be relative the global ones. Also, making install paths absolute by
default inhibits the proper behavior of functions like
`GNUInstallDirs_get_absolute_install_dir` which make relative install
paths absolute in a more complicated way.
Given all this, I will define a function like the one asked for in
https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a
similar use-case).
---
Original message:
Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for
complier-rt, just use it to define variables for the subdirs which
themselves are used.
This preserves compatibility, but later on we might consider getting rid
of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the
subdir variables directly.
---
There was a seaming bug where the (non-Apple) per-target libdir was
`${target}` not `lib/${target}`. I suspect that has to do with the docs
on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no
longer true, so I just went ahead and fixed it, allowing me to define
fewer and more sensible variables.
That last part should be the only behavior changes; everything else
should be a pure refactoring.
---
I added some documentation of these variables too. In particular, I
wanted to highlight the gotcha where `-DSomeCachePath=...` without the
`:PATH` will lead CMake to make the path absolute. See [1] for
discussion of the problem, and [2] for the brief official documentation
they added as a result.
[1]: https://cmake.org/pipermail/cmake/2015-March/060204.html
[2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options
In 38b2dec37e the problem was somewhat
misidentified and so `:STRING` was used, but `:PATH` is better as it
sets the correct type from the get-go.
---
D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands,
it should be feasible to follow both of these up with a simple patch for
compiler-rt analogous to the one for libcxx.
Reviewed By: phosek, #libc_abi, #libunwind
Differential Revision: https://reviews.llvm.org/D105765
This is necessary for from-scratch configurations to support the 32-bit
mode of the test suite.
Differential Revision: https://reviews.llvm.org/D105435
Now that Lit supports regular expressions inside XFAIL & friends, it is
much easier to write Lit annotations based on the triple.
Differential Revision: https://reviews.llvm.org/D104747
Before this patch, Lit parameters that were set as a result of CMake
options were not made available to from-scratch configs. This patch
serializes those parameters into the generated lit config file so that
they are available to all configs.
Differential Revision: https://reviews.llvm.org/D105047
Summary:
This patch enables calculating relative addresses with the DW_EH_PE_datarel encoding using a 'base' for AIX. After setting registers for jumping to the user code in gxx_personality_v0(), 'base' is cached in exception_header member catchTemp for use in __cxa_call_unexpected if ttypeIndex is less than 0 (exception spec).
Reviewed by: MaskRay, sfertile, compnerd, libc++abi
Differential Revision: https://reviews.llvm.org/D101298
Also, fix the last issue that prevented GCC 11 from passing the test
suite. Thanks to everyone else who fixed issues.
Differential Revision: https://reviews.llvm.org/D104315
Summary:
A -Wunused-parameter warning was introduced by patch rG7f0244afa828 [libc++abi] NFC: adding a new parameter base to functions for calculating… (authored by xingxue). The unused parameter base will be used in a follow-on patch D101298. This patch is to avoid the warning before D101298 is landed.
Reviewers: ldionne, sfertile, compnerd, libc++abi
Reviewed by: ldionne
Differential Revision: https://reviews.llvm.org/D104235
Instead, people should be using CMAKE_POSITION_INDEPENDENT_CODE to control
whether they want to use PIC or not. We should try to avoid reinventing
the wheel whenever CMake natively supports something.
This makes libc++abi consistent with libc++ and libunwind.
Differential Revision: https://reviews.llvm.org/D103973
Summary:
This NFC patch adds a new parameter base to functions invoked by scan_eh_tab() for calculating the address of the encoding with a relative value. base defaults to 0. This is in preparation for the AIX implementation which uses the DW_EH_PE_datarel encoding.
Reviewed by: MaskRay, sfertile, compnerd, libc++abi
Differential Revision: https://reviews.llvm.org/D101545
This matches the fact that we build the experimental library by default.
Otherwise, by default we'd be building the library but not testing it,
which is inconsistent.
Differential Revision: https://reviews.llvm.org/D102109
This was changed from using the header to using a forward declaration in
c4600ccf89, since older versions of the header didn't declare the
function. At this point, it's been declared for ~3.5 years, and it
should be pretty safe to assume that we can rely on the ASan interface
header to provide a declaration instead of needing to write our own.
Reviewed By: #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D103003
Now that we're passing -D_LIBCPP_BUILDING_LIBRARY to the libc++abi
build, -D_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS is redundant
(fb3a00c327/libcxx/include/exception (L120-L121)
is the only use of _LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS in
libc++, and that conditional also checks for _LIBCPP_BUILDING_LIBRARY).
Reviewed By: #libc_abi, phosek
Differential Revision: https://reviews.llvm.org/D102372
This fixes a long standing issue where the triple is not always set
consistently in all configurations. This change also moves the
back-deployment Lit features to using the proper target triple
instead of using something ad-hoc.
This will be necessary for using from scratch Lit configuration files
in both normal testing and back-deployment testing.
Differential Revision: https://reviews.llvm.org/D102012
When using the per-target runtime build, it may be desirable to have
different __config_site headers for each target where all targets cannot
share a single configuration.
The layout used for libc++ headers after this change is:
```
include/
c++/
v1/
<libc++ headers except for __config_site>
<target1>/
c++/
v1/
__config_site
<target2>/
c++/
v1/
__config_site
<other targets>
```
This is the most optimal layout since it avoids duplication, the only
headers that's per-target is __config_site, all other headers are
shared across targets. This also means that we no need two
-isystem flags: one for the target-agnostic headers and one for
the target specific headers.
Differential Revision: https://reviews.llvm.org/D89013
The StringView::substr now accepts a substring starting position and its
length instead of previous non-standard `from` & `to` positions.
All uses of two argument StringView::substr are in MicrosoftDemangler
and have 0 as a starting position, so no changes are necessary.
This also fixes a bug where attempting to extract a suffix with substr
(a `to` position equal to size) would return a substring without the
last character.
Fixing the issue should not introduce observable changes in the
demangler, since as currently used, a second argument to
StringView::substr is either: 1) a result of a successful call to
StringView::find and so necessarily smaller than size., or 2) in the
case of Demangler::demangleCharLiteral potentially equal to size, but
with demangler expecting more data to follow later on and failing either
way.
Reviewed By: #libc_abi, ldionne, erik.pilkington
Differential Revision: https://reviews.llvm.org/D100246
The new layout more closely matches the layout used by other compilers.
This is only used when LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is enabled.
Differential Revision: https://reviews.llvm.org/D100869
These variables were introduced during early work on the runtimes build
but were obsoleted by {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_LIBRARY_DIR.
Differential Revision: https://reviews.llvm.org/D99697
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
Differential Revision: https://reviews.llvm.org/D97572
This path would unblock the build of libc++ library on AIX:
1. Add _AIX guard for _LIBCPP_HAS_THREAD_API_PTHREAD
2. Use uselocale to actually take the locale setting
into account.
3. extract_mtime and extract_atime mod needed for AIX. As stat
structure on AIX uses internal structure st_timespec to store
time for binary compatibility reason. So we need to convert it
back to timespec here.
4. Do not build cxa_thread_atexit.cpp for libcxxabi on AIX.
Differential Revision: https://reviews.llvm.org/D97558
Both libc++ and libc++abi have options of merging with another archive. In the case of libc++abi, libunwind can be merged into it and in the case of libc++, libc++abi can be merged into it.
This is realized using add_custom_command with POST_BUILD and the usage of the CMake generator expression TARGET_LINKER_FILE in the arguments. For such generator expressions CMake doc states: "This target-level dependency does NOT add a file-level dependency that would cause the custom command to re-run whenever the executable is recompiled" [1]
This patch adds a DEPENDS argument to both add_custom_command invocations so that the archives also have a file-level dependency on the target they are merging with. That way, changes in say, libunwind source code, will be updated in the libc++abi and/or libc++ static libraries as well.
[1] https://cmake.org/cmake/help/v3.20/command/add_custom_command.html
Differential Revision: https://reviews.llvm.org/D98129
The runtimes build uses variables set by add_lit_testsuite to collect
testsuites from all the runtimes.
Differential Revision: https://reviews.llvm.org/D97913
A few files in libc++abi make use of libc++ headers and a few of those use threading primitives provided by libc++. Since libc++ has multiple threading APIs it may be necessary to override auto-detection.
This patch adds the LIBCXXABI_HAS_WIN32_THREAD_API which does roughly the same as LIBCXXABI_HAS_PTHREAD_API and the similarly named LIBCXX_HAS_WIN32_THREAD_API from libc++. Instead of using autodetection it will force the use of win32 threads instead of pthreads in headers included from libc++.
Without this patch, libc++abi may depend on pthreads if present on the users build environment, even if win32 threading was selected for libc++.
Differential revision: https://reviews.llvm.org/D98021
We always build the libraries in a Standard mode that supports noexcept,
so there's no need to use the _NOEXCEPT macro.
Differential Revision: https://reviews.llvm.org/D97700
Before this patch, we could only link against the back-deployment libc++abi
dylib. This patch allows linking against the just-built libc++abi, but
running against the back-deployment one -- just like we do for libc++.
Also, add XFAIL markup to flag expected errors.
Differential Revision: https://reviews.llvm.org/D91069
This is useful for projects that pull in libcxx and libcxxabi and build
them using out-of-tree build files, but don't make them sibling
directories (or don't call the sibling directories libcxx and libcxxabi
for some reason).
Fixes PR49313.
Differential Revision: https://reviews.llvm.org/D97379
Otherwise libc++abi.so fails to link on arm with undefined references to
some __aeabi_ builtins.
Differential Revision: https://reviews.llvm.org/D96574
Let's use -nostdlib++ rather than -nodefaultlibs when building libc++/libc++abi/libunwind libraries. The default is -nostdlib++ if supported by a build compiler like it is the case with clang, otherwise -nodefaultlibs is used as before.
This change is needed to avoid additional changes at the link step and not to increase the maintenance costs. If clang with -nodefaultlibs is used all the libraries which are removed but required would have to be manually added in. This set of libraries are unique and will send out.
The propose change will allow to make the link step simple for other platforms as well.
Reviewed By: #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D95875
Added __cxxabi_config.h includes to resolve _LIBCXXABI_ARM_EHABI and
proper building the forces_unwindX.cpp tests for the ARM/EHABI targets.
Differential Revision: https://reviews.llvm.org/D96378
libunwind ARM EHABI does not support _Unwind_ForcedUnwind yet.
In addition, ARM EHABI makes `_Unwind_Exception` a typedef so
`struct _Unwind_Exception*` cannot be used.
Forced unwinding is like a foreign exception, which can be caught by `catch (...)` and rethrown.
If not rethrown, `__cxa_end_cath` will call `_Unwind_DeleteException` to destroy the object.
The behavior going through empty `throw()` and non-empty `throw(int)` is not
clear (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98785), so I do not add such
tests.
Differential Revision: https://reviews.llvm.org/D95200
The two operations have acted differently since Clang 8, but were
unfortunately mangled the same. The new mangling uses new "vendor
extended expression" syntax proposed in
https://github.com/itanium-cxx-abi/cxx-abi/issues/112
GCC had the same mangling problem, https://gcc.gnu.org/PR88115, and
will hopefully be switching to the same mangling as implemented here.
Additionally, fix the mangling of `__uuidof` to use the new extension
syntax, instead of its previous nonstandard special-case.
Adjusts the demangler accordingly.
Differential Revision: https://reviews.llvm.org/D93922
1.
All `_URC_HANDLER_FOUND` return values need to set `landingPad`
and its value does not matter for `_URC_CONTINUE_UNWIND`. So we
can always set `landingPad` to unify code.
2.
For an exception specification (`ttypeIndex < 0`), we can check `_UA_FORCE_UNWIND` first.
3.
The so-called type 3 search (`actions & _UA_CLEANUP_PHASE && !(actions & _UA_HANDLER_FRAME)`)
is actually conceptually wrong. For a catch handler or an unmatched dynamic
exception specification, `_UA_HANDLER_FOUND` should be returned immediately. It
still appeared to work because the `ttypeIndex==0` case would return
`_UA_HANDLER_FOUND` at a later time.
This patch fixes the conceptual error and simplifies the code by handling type 3
the same way as type 2 (which is also what libsupc++ does).
The only difference between phase 1 and phase 2 is what to do with a cleanup
(`actionEntry==0`, or a `ttypeIndex==0` is found in the action record chain):
phase 1 returns `_URC_CONTINUE_UNWIND` while phase 2 returns `_URC_HANDLER_FOUND`.
Reviewed By: #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D93190
We've been using this patch in Android so we can avoid including the
demangler in libc++.so. It comes with a rather large cost in RSS and
isn't commonly needed.
Reviewed By: #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D88189
cmake_minimum_required(VERSION) calls cmake_policy(VERSION),
which sets all policies up to VERSION to NEW.
LLVM started requiring CMake 3.13 last year, so we can remove
a bunch of code setting policies prior to 3.13 to NEW as it
no longer has any effect.
Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D94374
In 7cd67904f7, we removed the unnecessary nullptr checks from the libc++abi
definition of operator delete, but we forgot to update the definition in
libc++ (damn code duplication!). Then, in d4a1e03c5f, I synced the
definitions across libc++ and libc++abi, but I did it the wrong way around.
I re-added the if() checks to libc++abi instead of removing them from libc++.
In ef74f0fdc3, we re-removed the if() check from operator delete, but
only in libc++abi. This patch corrects this mess and removes it
consistently in libc++ and libc++abi.
Differential Revision: https://reviews.llvm.org/D93473
In three cases we call `scan_eh_tab` to parse LSDA:
* `actions & _UA_SEARCH_PHASE`
* `actions & _UA_CLEANUP_PHASE && actions & _UA_HANDLER_FRAME && !native_exception`
* `actions & _UA_CLEANUP_PHASE && !(actions & _UA_HANDLER_FRAME)`
Check
`actions & _UA_CLEANUP_PHASE && actions & _UA_HANDLER_FRAME && native_exception` first,
then we can move three `scan_eh_tab` into one place.
Another simplification is that we can check whether the result of `scan_eh_tab`
is `_UA_CONTINUE_UNWIND` or `_UA_FATAL_PHASE1_ERROR` first. Then many of the
original checks will be dead and can thus be deleted.
Reviewed By: #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D93186
Similar to D52401. Normally operator delete is defined in libc++abi
(LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS is off by default).
C89 4.10.3.2 The free function
C99 7.20.3.2 The free function
C11 7.22.3.3 The free function
If ptr is a null pointer, no action shall occur.
free on MSDN:
If memblock is NULL, the pointer is ignored and free immediately returns.
Reviewed By: #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D93339
Under the relative vtables ABI, __dynamic_cast will not work since it assumes
the vtable pointer is 2 ptrdiff_ts away from the start of the vtable (8-byte
offset to top + 8-byte pointer to typeinfo) when it is actually 8 bytes away
(4-byte offset to top + 4-byte offset to typeinfo). This adjusts the logic under
__dynamic_cast and other areas vtable calculations are done to support this ABI
when it's used.
Differential Revision: https://reviews.llvm.org/D77606
We create threads using std::thread in various places in the test suite.
However, the usual std::thread constructor may not work on all platforms,
e.g. on platforms where passing a stack size is required to create a thread.
This commit introduces a simple indirection that makes it easier to tweak
how threads are created inside the test suite on various platforms. Note
that tests that are purposefully calling std::thread's constructor directly
(e.g. because that is what they're testing) were not modified.
This will fix remaining failures on gcc-9 buildbot: http://lab.llvm.org:8011/#/builders/101.
gcc-8 and gcc-9 do not support constexpr destructors nor constexpr allocation.
Fix gcc warnings: -Wconversion, -Wpragmas.
This should make the builder http://lab.llvm.org:8011/#/builders/101/ happy.
It uses gcc-9 and not Tip-Of-Trunk as its name indicates BTW.
GCC-10 passes all these tests.
Fix gcc warnings: -Wsign-compare, -Wparentheses, -Wpragmas.
Reviewed By: ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D92099
There were a couple of places where we needed to call the underlying
platform's aligned allocation/deallocation function. Instead of having
the same logic all over the place, extract the logic into a pair of
helper functions __libcpp_aligned_alloc and __libcpp_aligned_free.
The code in libcxxabi/src/fallback_malloc.cpp looks like it could be
simplified after this change -- I purposefully did not simplify it
further to keep this change as straightforward as possible, since it
is touching very important parts of the library.
Also, the changes in libcxx/src/new.cpp and libcxxabi/src/stdlib_new_delete.cpp
are basically the same -- I just kept both source files in sync.
The underlying reason for this refactoring is to make it easier to support
platforms that provide aligned allocation through C11's aligned_alloc
function instead of posix_memalign. After this change, we'll only have
to add support for that in a single place.
Differential Revision: https://reviews.llvm.org/D91379
This has been a long-standing TODO item, however we have now been requiring
a monorepo layout to build libc++ and libc++abi for a while now. Hence,
we can fix this code duplication issue now.
Note that it's still not super pretty to reach into libc++ to include
headers, but it's better than having duplicated code which can get out
of sync.
When building the runtimes, it's very important not to add rpaths unless
the user explicitly asks for them (the standard way being CMAKE_INSTALL_RPATH),
or to change the install name dir unless the user requests it (via
CMAKE_INSTALL_NAME_DIR).
llvm_setup_rpath() would override the install_name_dir of the runtimes
even if CMAKE_INSTALL_NAME_DIR was specified to something, which is wrong
and in fact even "dangerous" for the runtimes.
This issue was discovered when trying to build libc++ and libc++abi as
system libraries for Apple, where we set the install name dir to /usr/lib
explicitly. llvm_setup_rpath() would cause libc++ to have the wrong install
name dir, and for basically everything on the system to fail to load.
This was discovered just now because we previously used something closer
to a standalone build, where llvm_setup_rpath() wouldn't exist, and hence
not be used.
This is a revert of the following commits:
libunwind: 3a667b9bd8
libc++abi: 4877063e19
libc++: 88434fe05f
Those added llvm_setup_rpath() for consistency, so it seems reasonable
to revert.
Differential Revision: https://reviews.llvm.org/D91099
Summary:
Before this patch, we could only link against the back-deployment libc++abi
dylib. This patch allows linking against the just-built libc++abi, but
running against the back-deployment one -- just like we do for libc++.
Also, add XFAIL markup to flag expected errors.
Previously, these had to be set manually when building each of the
projects standalone, in order to get proper symbol visibility when
combining the two libraries.
Differential Revision: https://reviews.llvm.org/D90021
This is a massive revert of the following commits (from most revent to oldest):
2b9b7b5775.
529ac3319728270234f169c2087283b5aa67446e5d796645d6
After checking-in the __config_site change, a lot of things started breaking
due to widespread reliance on various aspects of libc++'s build, notably the
fact that we can include the headers from the source tree, but also reliance
on various "internal" CMake variables used by the runtimes build and compiler-rt.
These were unintended consequences of the change, and after two days, we
still haven't restored all the bots to being green. Instead, now that I
understand what specific areas this will blow up in, I should be able to
chop up the patch into smaller ones that are easier to digest.
See https://reviews.llvm.org/D89041 for more details on this adventure.
In 5d796645, we stopped looking at the LIBCXXABI_LIBCXX_INCLUDES variable,
which broke users of the Standalone build. This patch reinstates that
variable, however it must point to the *installed* path of the libc++
headers, not the libc++ headers in the source tree (which has always
been the case, but wasn't enforced before).
If LIBCXXABI_LIBCXX_INCLUDES points to the libc++ headers in the source
tree, the `__config_site` header will fail to be found.
Copy over the compiler detection structure from libcxx, and set
_LIBCXXABI_WEAK like _LIBCPP_WEAK is set in libcxx.
This allows users to override operator new/delete, if using those
operators from libcxxabi instead of from libcxx.
Differential Revision: https://reviews.llvm.org/D89863
This commit should really be named "Workaround external projects depending
on libc++ build system implementation details". It seems that the compiler-rt
build (and perhaps other projects) is relying on the fact that we copy libc++
and libc++abi headers to `<build-root>/include/c++/v1`. This was changed
by 5d796645, which moved the headers to `<build-root>/projects/libcxx/include/c++/v1`
and broke the compiler-rt build.
I'm committing this workaround to fix the compiler-rt build, but we should
remove reliance on implementation details like that. The correct way to
setup the compiler-rt build would be to "link" against the `cxx-headers`
target in CMake, or to run `install-cxx-headers` using an appropriate
installation prefix, and then manually add a `-I` path to that location.
While running this test on a bare metal target, I got an error as 'sleep' was not available on that system. As 'sleep' call is not doing anything useful for cases when _LIBCXXABI_HAS_NO_THREADS is defined. This patch puts it under this check.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D89871
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
This commit was originally applied in 1e46d1aa3 and reverted in eb60c487
because it broke the libc++abi and libunwind test suites. This has now
been fixed.
Differential Revision: https://reviews.llvm.org/D89041
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
Differential Revision: https://reviews.llvm.org/D89041
This patch ensures that __shared_weak_count provides a consistent vtable
regardless of if RTTI is enabled or if we are targeting a static or shared
libc++ build.
This patch is technically ABI breaking, but only for a very specific
configuration that no vendor should be shipping.
Note that _LIBCPP_BUILD_STATIC is not normally defined when building
libc++.a, but instead it must be manually provided by the user or the
__config_site.
Differential Revision: https://reviews.llvm.org/D32838
Previously, we would define new/delete in both libc++ and libc++abi.
Not only does this cause code bloat, but also it's technically an ODR
violation since we don't know which operator will be selected. Furthermore,
since those are weak definitions, we should strive to have as few of them
as possible (to improve load times).
My preferred choice would have been to put the operators in libc++ only
by default, however that would create a circular dependency between
libc++ and libc++abi, which GNU linkers don't handle.
Folks who want to ship new/delete in libc++ instead of libc++abi are
free to do so by turning on LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS at
CMake configure time.
On Apple platforms, this shouldn't be an ABI break because we re-export
the new/delete symbols from libc++abi. This change actually makes libc++
behave closer to the system libc++ shipped on Apple platforms.
On other platforms, this is an ABI break for people linking against libc++
but not libc++abi. However, vendors have been consulted in D68269 and no
objection was raised. Furthermore, the definitions can be controlled to
appear in libc++ instead with the CMake option.
Differential Revision: https://reviews.llvm.org/D68269
This is the libcxxabi counterpart of D89545, and would have been part
of that patch if I'd spotted it soon enough (oops). One test in
libcxxabi is using the `%lu` printf format to refer to `size_t`, which
should be `%zu`.
Reviewed By: ldionne, #libc_abi
Differential Revision: https://reviews.llvm.org/D89547
Remove check for standalone and shared library mode in libcxxabi to
allow including tests in said mode. This check prevented running the
tests in standalone mode with static libraries, which is the case for
baremetal targets.
Fix check-unwind target trying to use a non-existent llvm-lit executable
in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to
libunwind in order to make the tests work in standalone mode.
Reviewed By: ldionne, #libc_abi, #libc
Differential Revision: https://reviews.llvm.org/D86540
We used <iostream> in several places where we don't actually need the
full power of <iostream>, and where using basic `std::printf` is enough.
This is better, since `std::printf` can be supported on systems that don't
have a notion of locales, while <iostream> can't.
There are several places in LLVM's CMake setup that try to remove the
`stdlib=...` flag from the CMake flags. All this code however only considered
the `-stdlib=` variant of the flag but not the alternative spelling with a
double dash. This causes that when one adds `--stdlib=...` to the user-provided
CMake flags that this gets transformed into just `-` which ends up causing the
build system to think it should read the source from stdin (which then lead to
very confusing build errors).
This just adds the alternative spelling before the`-stdlib=` variant in all
these places
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D87133
This is needed when running the tests in Freestanding mode, where main()
isn't treated specially. In Freestanding, main() doesn't get mangled as
extern "C", so whatever runtime we're using fails to find the entry point.
One way to solve this problem is to define a symbol alias from __Z4mainiPPc
to _main, however this requires all definitions of main() to have the same
mangling. Hence this commit.
This reverts commit c7d4aa711a. I am still investigating the issue,
but it looks like that commit has an interaction with ld64 that causes
new/delete weak re-exports not to work properly anymore. This is weird
because this commit did not touch the exports of new/delete -- I am
still investigating.
This is a temporary workaround until the new/delete situation is made
better (i.e. we don't include new/delete in both libc++ and libc++abi
by default).
Instead of managing two copies of the symbol lists, reuse the same list
in libc++abi and libc++.
Differential Revision: https://reviews.llvm.org/D88623
Setting _LIBCPP_HAS_NO_THREADS is needed when building libcxxabi without
threads in standalone mode. This is useful when target WASM. Otherwise,
you get an error like "No thread API" when building libcxxabi.
It would be better to link against a properly-configured libc++ headers
CMake target when building libc++abi instead, but we don't generate such
targets yet.
Thanks to Matthew Bauer for the patch.
Differential Revision: https://reviews.llvm.org/D60743
The needs of back-deployment testing currently require two different
ways of running the test suite: one based on the deployment target,
and one based on the target triple. Since the triple includes all the
information we need, it's better to have just one way of doing things.
Furthermore, `--param platform=XXX` is also supersedded by using the
target triple. Previously, this parameter would serve the purpose of
controling XFAILs for availability markup errors, however it is possible
to achieve the same thing by using with_system_cxx_lib only and using
.verify.cpp tests instead, as explained in the documentation changes.
The motivation for this change is twofold:
1. This part of the Lit config has always been really confusing and
complicated, and it has been a source of bugs in the past. I have
simplified it iteratively in the past, but the complexity is still
there.
2. The deployment-target detection started failing in weird ways in
recent Clangs, breaking our CI. Instead of band-aid patching the
issue, I decided to remove the complexity altogether by using target
triples even on Apple platforms.
A follow-up to this commit will bring the test suite in line with
the recommended way of handling availability markup tests.
Louis Dionne