As announced on libcxx-dev at [1], the old libc++ testing format is being
removed in favour of the new one. Follow-up commits will clean up the
code that is dead after the removal of this option.
[1]: http://lists.llvm.org/pipermail/libcxx-dev/2020-June/000885.html
This is necessary for standalone builds where the libc++ in use has a
custom configuration set up inside __config_site -- one needs to build
libc++abi against the installed headers of libc++ (which are properly
configured) instead of the ones inside libcxx/include.
See https://reviews.llvm.org/rGe619e9d#927848 for details.
The integration between CMake and executor selection in the new format
wasn't very flexible -- only the default executor and SSH executors were
supported.
This patch makes it possible to specify arbitrary executors with the new
format. With the new testing format, a custom executor is just a script
that gets called with a command-line to execute, and some arguments like
--env, --codesign_identity and --execdir. As such, the default executor
is just run.py.
Remote execution with the SSH executor can be achived by specifying
LIBCXX_EXECUTOR="<path-to-ssh.py> --host <host>". Similarly, arbitrary
scripts can be provided.
Since we have the monorepo, libc++abi's build requires a sibling checkout
of the libc++ sources. Hence, the logic for finding libc++ can be greatly
simplified.
Instead of passing file dependencies individually, assume that the
whole content of the unique test directory is a dependency. This
simplifies the test harness significantly, by making %T the directory
that contains everything required to run a test. This also removes the
need for the %{file_dependencies} substitution, which is removed by this
patch.
Furthermore, this patch also changes the harness to execute tests locally
inside %T, so as to avoid creating a separate directory for no purpose.
This clarifies the difference between test for exception support in
libc++abi tests and support for exceptions built into libc++abi.
This also removes the rather confusing similarity between the
_LIBCXXABI_NO_EXCEPTIONS and LIBCXXABI_HAS_NO_EXCEPTIONS macros.
Finally, TEST_HAS_NO_EXCEPTIONS is also detected automatically based
on -fno-exceptions, so it doesn't have to be specified explicitly
through Lit's compile_flags.
0e04342ae0 simplified exceptions-related configurations for libc++abi
and libunwind by reusing the logic in libc++. However, it missed the fact
that libc++abi and libunwind were overriding libc++'s handling of exceptions.
This commit removes special handling in libc++abi and libunwind to use
the logic in libc++, which is the right one.
First, libc++abi doesn't need to add the no-exceptions Lit feature itself,
since that is already done in the config.py for libc++, which it reuses.
Specifically, config.enable_exceptions is set based on @LIBCXXABI_ENABLE_EXCEPTIONS@
in libc++abi's lit.cfg.in, and libc++'s config.py handles that correctly.
Secondly, libunwind's LIBUNWIND_ENABLE_EXCEPTIONS is never set (it's
probably a remnant of copy-pasting code between the runtime libraries),
so the library is always built with exceptions disabled (which makes
sense since it implements the runtime support for exceptions).
Conversely, the test suite is always run with exceptions enabled
(not sure why), but that is preserved by the default behavior of
libc++'s config.py.
Since <unwind.h> is in the SDK, not in /usr/include, the XFAILs must
be predicated on the compiler version (ideally even on the SDK version)
instead of the target system version.
C++98 and C++03 are effectively aliases as far as Clang is concerned.
As such, allowing both std=c++98 and std=c++03 as Lit parameters is
just slightly confusing, but provides no value. It's similar to allowing
both std=c++17 and std=c++1z, which we don't do.
This was discovered because we had an internal bot that ran the test
suite under both c++98 AND c++03 -- one of which is redundant.
Differential Revision: https://reviews.llvm.org/D80926
When building the system libc++abi for Apple, we use CrashReporterClient
to provide better crash logs when calling abort(). This is exemplified by
the fact that we test for the presence of <CrashReporterClient.h> in
abort_message.cpp.
However, we must link against CrashReporterClient.a in order to get that
functionality, otherwise we get a linking error.
Slightly older Clangs seem to think they are more clever than they really
are, and they think the code can never be executed. The code can actually
be executed in case the exception runtime is mis-implemented, which is
exactly what this test is testing. This commit just disables the spurious
warning.
Android doesn't have a libgcc_s and uses libgcc instead, so adjust the
build accordingly. This matches compiler-rt's build setup. libc++abi and
libunwind were already checking for libgcc but in a different context.
This change makes them search only for libgcc on Android now, but the
code to link against libgcc if it were present was already there.
Reviewed By: #libc, #libc_abi, #libunwind, rprichard, srhines
Differential Revision: https://reviews.llvm.org/D78787
Instead of the ad-hoc #define _LIBCXX_DYNAMIC_FALLBACK, provide an option
to enable the setting when building libc++abi. Also use the occasion to
rename the option to something slightly more descriptive.
Note that in the future, it would be great to simply remove this option
altogether. However, in the meantime, it seems better to have it be an
official option than something ad-hoc.
Instead of having different names for the same Lit feature accross code
bases, use the same name everywhere. This NFC commit is in preparation
for a refactor where all three projects will be using the same Lit
feature detection logic, and hence it won't be convenient to use
different names for the feature.
Differential Revision: https://reviews.llvm.org/D78370
This upstreams a fix that Howard made a long time ago, where so many
errors would be logged that applications were becoming sluggish. With
this patch, the first three errors will be printed, and after that the
printing frequency decreases exponentially.
_LIBCXX_DYNAMIC_FALLBACK is only enabled on Apple platforms, so this
should be NFC for other platforms.
rdar://14996273
Differential Revision: https://reviews.llvm.org/D78330
We previously tried re-exporting symbols that didn't exist when
exceptions were disabled. Note that building libc++abi without
exceptions still doesn't work when linking against the default-provided
libSystem.dylib, because it transitively depends on libobjc.dylib,
and that requires __gxx_personality_v0. But building libc++abi
with exceptions and libc++ without exceptions does work.
Summary:
This patch is to fix the parsing of long double literals encoded with the e prefix on PowerPC and S390. For both PowerPC and S390, type code e is used for 64-bit long double literals and g is used for 128-bit long double literals. libcxxabi test case test_demangle.pass.cpp fails without the fix.
Authored by: xingxue-ibm
Reviewers: hubert.reinterpretcast, jasonliu, erik.pilkington, uweigand, mclow.li
sts, libc++abi
Reviewed by: hubert.reinterpretcast, erik.pilkington
Differential Revision: https://reviews.llvm.org/D74163
The new format should be equivalent to the old format, and it is now the
default format when running the libc++ tests. This commit changes the
libc++abi tests to use the new format by default too. If unexpected failures
are discovered, it should be fine to revert this commit until they are
addressed.
Also note that it is still possible to use the old format by passing
`--param=use_old_format=True` when running Lit for the time being.
The LitConfig is shared across the whole test suite. However, since
enabling recursive expansion can be a breaking change for some test
suites, it's important to confine the setting to test suites that
enable it explicitly.
Note that other issues were raised with the way recursiveExpansionLimit
operates. However, this commit simply moves the setting to the right
place -- the mechanism by which it works can be improved independently.
Differential Revision: https://reviews.llvm.org/D77415
This new test format is simpler and more flexible. It creates Lit ShTests
on the fly that reuse existing substitutions (like %{cxx}) instead of
having complex logic in Python to run the tests. This has the benefit
that virtually no coding is required to customize how the test suite is
run -- one can achieve pretty much anything by defining the appropriate
substitutions in a simple lit.cfg file.
For example, in order to run the tests on an embedded device after
building with a specific SDK, one can set the %{cxx} and %{compile_flags}
substitutions to use that SDK, and the %{exec} substitution to the ssh.py
script currently used for .sh.cpp tests with a remote executor. Dealing with
the SSHExecutor becomes unnecessary, since all tests are treated like ShTests.
As a side effect of this design, configuration files for the test
suite can be as simple as:
config.substitutions.append(('%{cxx}', '<path-to-compiler>'))
config.substitutions.append(('%{compile_flags}', '<flags>'))
config.substitutions.append(('%{link_flags}', '<flags>'))
config.substitutions.append(('%{exec}', '<script-to-execute>'))
This should allow storing lit.cfg files for various configurations
directly in the repository instead of relying on complicated logic
in config.py to set up the right flags. I've found numerous problems
in that logic in the past years, and it seems like having simple and
explicit configuration files for the configurations we support is
going to solve most of these problems. Specifically, I am hoping to
store configuration files for testing other Standard Libraries in
the repository.
Improving the interaction with the test suite configuration is still a
work in progress, so for now this test format reuses the substitutions and
available features that are set up by the current config.py.
This new test format should support pretty much everything that the current
test format supports, however it will not be enabled by default at first to
make sure we're satisfied with it. For a short period of time, the new format
will require `--param=use_new_format=True` to be enabled, however it is a very
short term goal to replace the current testing format entirely and to simplify
the configuration accordingly.
Differential Revision: https://reviews.llvm.org/D77338
To avoid wasting the valuable time of contributors, add a link to a
blocked review to document additional issues with the removal of some
GCC 4.9 workaround.
We will soon start removing technical debt and sharing code between the
two directories, so this first step is meant to discover potential places
where the libraries are built outside of a monorepo layout. I imagine
this could happen as a remnant of the pre-monorepo setup.
This was discussed on the libcxx-dev mailing list and we got overall
consensus on the direction. All consumers of libc++ and libc++abi
should already be doing so through the monorepo, however it is
possible that we catch some stragglers with this patch, in which
case it may need to be reverted temporarily.
Differential Revision: https://reviews.llvm.org/D76102
We've been meaning to remove those targets for a while, and the fix is
simple enough cause they're all just aliases to other targets.
This is a re-application of f383fb40b1, wich was reverted in 04d48111b
because the build bots had not been updated yet. The build bot configurations
have now been updated not to use the deprecated targets, and I verified
that they were using the non-deprecated targets, so we should be good
unless I missed a bot.
Differential Revision: https://reviews.llvm.org/D76104
lit is not very clever when it performs substitution on RUN lines. It
simply looks for a match anywhere in the line (without tokenization)
and replaces it by the expansion. This means that a RUN line containing
e.g. `-verify-ignore-unexpected=note` wouod be expanded to
`-verify-ignore-unexpected=<substitution for not>e`, which is
surprising and nonsensical.
It also means that something like `%compile_module` could be expanded
to `<substitution-for-%compile>_module` or to the correct substitution,
depending on the order in which substitutions are evaluated by lit.
To avoid such problems, it is a good habit to delimit custom substitutions
with some token. This commit does that for all substitutions used in the
libc++ and libc++abi test suites.
This reverts commit f383fb40b. It looks like several of our build bots
are still using the legacy target names, so we'll change those before
we commit this change again.
We've been meaning to remove those targets for a while, and the fix is
simple enough cause they're all just aliases to other targets.
There's no doubt this commit will break some CI systems, however the
fix is trivial.
Differential Revision: https://reviews.llvm.org/D76104
Since the atomic_support.h header of libc++abi is considered technical
debt (since we should use libc++'s), it's better not to add new
definitions to it, which makes it diverge from the original libc++
header even more.
Differential Revision: https://reviews.llvm.org/D75950
It seems to me that abort_message.h is always included in a C++ file, so
it's fine to assume that it's C++ code.
Differential Revision: https://reviews.llvm.org/D76027
Summary:
The return type of __cxa_finalize is documented as void in the Itanium
C++ ABI, and it is void in various C libraries.
Reviewers: EricWF, ldionne, compnerd, mclow.lists, MaskRay
Reviewed By: MaskRay
Subscribers: MaskRay, dexonsmith, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75795
Win64 isn't LP64, it's LLP64, but there's no __LLP64__ predefined -
just check _WIN64 in addition to __LP64__.
This fixes compilation after static asserts about the struct layout
were added in f2a436058f.
Differential Revision: https://reviews.llvm.org/D73838
Summary:
Preserve the old ABI for __cxa_exception and __cxa_dependent_exception
on 64 bit platforms or ARM_EHABI platforms.
After r276215, libunwind in llvm-project labels _Unwind_Exception to be
double word aligned. That change implictly adds a padding before
unwindHeader field in __cxa_exception and __cxa_dependent_exception.
Preserve the same negative offsets in those struct by moving the padding
to the beginning of the field.
The assumption here is that if the ABI is not aware of the padding before
unwindHeader and put the referenceCount/primaryException in there, no padding
should exist before unwindHeader.
Reviewers: EricWF, mclow.lists, ldionne, jroelofs, dexonsmith, rjmccall, compnerd, phosek, ahatanak
Reviewed By: rjmccall
Subscribers: hans, smeenai, kristof.beyls, christof, jkorous, ributzka, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D72543
libc++ on Android needs to be linked against libandroid_support on API
levels less than 21 to provide needed functions that aren't in the libc
on those platforms (e.g. posix_memalign for libcxxabi). libc++ from the
NDK is a linker script that pulls in libandroid_support, but for
building libc++ itself, we need to explicitly add libandroid_support as
a dependency. Moreover, libc++ headers reference the functions provided
by libandroid_support, so it needs to be added as a public dependency.
Differential Revision: https://reviews.llvm.org/D73516
These names have been changed from CamelCase to camelCase, but there were
many places (comments mostly) that still used the old names.
This change is NFC.
builds.
Fix a libc++abi test that was incorrectly checking for threading
primitives even when threading was disabled.
Additionally, temporarily XFAIL some module tests that fail because
the <atomic> header is unsupported but still built as a part of the
std module.
To properly address this libc++ would either need to produce a different
module.modulemap for single-threaded configurations, or it would need
to make the <atomic> header not hard-error and instead be empty
for single-threaded configurations
Summary:
Right now the only way to force libc++abi tests to link with the static version of libc++abi is to set `LIBCXXABI_ENABLE_SHARED` to `OFF`. However, this doesn't work when libc++abi is built as standalone project because of [this](54c5224203/libcxxabi/CMakeLists.txt (L503-L519)).
This change allows specifying the version of the library for tests to link with.
This is useful for remote testing, for example, with `SSHExecutor`, where we _have_ to link with libc++abi statically.
Two new CMake options are introduced here: `LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXXABI` and `LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXX`. They can be set to `OFF` to tell the test utility to link tests with the static libraries.
It shouldn't break anything, because the default values of these options are set such that the test utility will behave the same way.
Reviewers: EricWF, mclow.lists, phosek, mehdi_amini, ldionne, jroelofs, bcraig
Subscribers: mgorny, christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D71894
These are a part of the libc so linking these explicitly isn't necessary
and embedding these as deplibs causes link time error.
This issues was introduced in a9b5fff which changed how we emit deplibs.
Differential Revision: https://reviews.llvm.org/D71135
This is a followup to 35bc5276ca. It fixes the dependent libs usage
in libcxx and libcxxabi to link pthread and rt libraries only if CMake
detects them, rather than based on explicit platform blacklist.
Differential Revision: https://reviews.llvm.org/D70888
We build with `-nostdinc++` and add our own header path via
`LIBCXXABI_LIBCXX_INCLUDES`. However cmake tried to be clever and if
`LIBCXXABI_LIBCXX_INCLUDES` happens to match the compilers system path
it will remove the `-I` flag meaning we can't access any C++ headers.
Ideally cmake would be able see that we are using `-nostdinc++` and
disable this behaviour.
Differential Revision: https://reviews.llvm.org/D69973
This class was a bit overengineered, and was triggering some PVS warnings.
Instead, put strings into a NameType and let clients unconditionally treat it
as a Node.
Summary: The implementation of P1152R4 in Clang has resulted in some deprecation warnings appearing in the libc++ and libc++abi test suite. Fix or suppress these warnings.
Reviewers: mclow.lists, EricWF
Subscribers: christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68879
llvm-svn: 375307
That option controls the 'VERSION' attribute of the libc++abi shared
library, which in turn controls the name of the actual dylib being
produced.
llvm-svn: 373949
These flags are already set when we create the cxxabi_shared target
using the SOVERSION and VERSION target properties, and the install_name
was already being overriden to '@rpath/libc++abi.1.dylib' by CMake
because no 'CMAKE_INSTALL_NAME_DIR' option was specified. So this is
effectively a removal of dead code with no intended functionality change.
The only think we're losing here is that we used to link against
libSystem.B.dylib instead of libSystem.dylib when building libc++abi
for macOS 10.6 -- however, I strongly suspect nobody's building
libc++abi from source for that target anymore.
llvm-svn: 373934
On Apple platforms, libSystem is an umbrella for all other system
libraries, and libpthread (and friends) are actually just symlinks
to libSystem.
llvm-svn: 373770
Summary:
Those functions started being mistakenly exported from the libc++abi
shared library after commit r344152 in 2018. Removing these symbols is
technically an ABI break. However, they are not part of the C++ ABI,
they haven't ever been re-exported from libc++, and they are not
declared in any public header, so it's very unlikely that calls to
these functions exist out there. Also, the functions have reserved
names, so any impacted user would have to have tried really hard
being broken by this removal.
Note that avoiding this kind of problem is exactly why we're now
controlling exported symbols explicitly with a textual list.
Also note that applying the hidden visibility attribute is necessary
because the list of exported symbols is only used on Apple platforms
for the time being.
Reviewers: phosek, mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68357
llvm-svn: 373602
This reduces the (circular) dependency of libc++abi on a C++ standard
library. Outside of the demangler which uses fancier C++ features, the
only C++ headers now required by libc++abi are pretty much <new> and
<exception>, and that's because libc++abi defines some types that are
declared in those headers.
llvm-svn: 373381
Both arm32 armv7/armv8 bots which do not use compiler-rt are failing
to a linking issue:
[100%] Built target cxxabi_static
CMakeFiles/cxxabi_shared.dir/cxa_demangle.cpp.o: In function `(anonymous namespace)::itanium_demangle::OutputStream::writeUnsigned(unsigned long long, bool)':
/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv7-linux-noexceptions/llvm/projects/libcxxabi/src/demangle/Utility.h:55: undefined reference to `__aeabi_uldivmod'
/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv7-linux-noexceptions/llvm/projects/libcxxabi/src/demangle/Utility.h:56: undefined reference to `__aeabi_uldivmod'
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)
It seems after r371273 OutputStream is used more extensively and
is pulling OutputStream::writeUnsigned (which thus requires unsigned
integer module).
The straightfoward fix is to explicit link against libgcc if
compiler-rt is not used.
llvm-svn: 372921
version after r371273.
Also fix a minor issue in r371273 that only surfaced after template
instantiation from LLVM's use of the demangler.
llvm-svn: 371274
This implements demangling support for the mangling extensions specified
in https://github.com/itanium-cxx-abi/cxx-abi/pull/85, much of which is
implemented in Clang r359967 and r371004.
Specifically, this provides demangling for:
* <template-param-decl> in <lambda-sig>
* <template-param> with non-zero level
* lambda-expression literals (not emitted by Clang yet)
* nullptr literals
* string literals
(The final two seem unrelated, but handling them was necessary in order
to disambiguate between lambda expressions and the other forms of
literal for which we have a type but no value.)
When demangling a <lambda-sig>, we form template parameters with no
corresponding argument, so we cannot substitute in the argument in the
demangling. Instead we invent synthetic names for the template
parameters (eg, '[]<typename $T>($T *x)').
llvm-svn: 371273
Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).
The commit also adds support for running the PSTL tests as part of
the libc++ test suite.
The first attempt to commit this failed because it exposed a bug in the
tests for modules. Now that this has been fixed, it should be safe to
commit this.
Reviewers: EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60480
llvm-svn: 367903
r362048 added support for ELF dependent libraries, but broke Android
build since Android does not have libpthread. Remove the dependency on
the Android build.
Differential Revision: https://reviews.llvm.org/D65098
llvm-svn: 366734
This reverts r366593, which caused unforeseen breakage on the build bots.
I'm reverting until the problems have been figured out and fixed.
llvm-svn: 366603
Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).
The commit also adds support for running the PSTL tests as part of
the libc++ test suite.
Reviewers: rodgert, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60480
llvm-svn: 366593
When exceptions are disabled, avoid their processing altogether.
This avoids pulling in the depenency on demangler significantly
reducing binary size when statically linking against libc++abi
built without exception support.
Differential Revision: https://reviews.llvm.org/D64191
llvm-svn: 365944
Summary: I'm pretty sure it's not used anymore, at least it isn't used at Apple.
Reviewers: EricWF, Bigcheese
Subscribers: christof, jkorous, dexonsmith, jfb, mstorsjo, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D63297
llvm-svn: 363737
ar doesn't produce the correct results when used for linking static
archives on Apple platforms, so instead use libtool -static which is
the official way to build static archives on those platforms.
Differential Revision: https://reviews.llvm.org/D62770
llvm-svn: 362311
These seemed to have been used in the past but were since removed
by the add_compile_flags_if_supported functions that combine these
these checks and adding the flag, but the original checks were never
removed.
Differential Revision: https://reviews.llvm.org/D62566
llvm-svn: 362058
This fixes the issue introduced by r362048 where we always use
pragma comment(lib, ...) for dependent libraries when the compiler
is Clang, but older Clang versions don't support this pragma so
we need to check first if it's supported before using it.
llvm-svn: 362055
As of r360984, LLD supports dependent libraries feature for ELF.
libunwind, libc++abi and libc++ have library dependencies: libdl librt
and libpthread, which means that when libunwind and libc++ are being
statically linked (using -static-libstdc++ flag), user has to manually
specify -ldl -lpthread which is onerous.
This change includes the lib pragma to specify the library dependencies
directly in the source that uses those libraries. This doesn't make any
difference when using linkers that don't support dependent libraries.
However, when using LLD that has dependent libraries feature, users no
longer have to manually specifying library dependencies when using
static linking, linker will pick the library automatically.
Differential Revision: https://reviews.llvm.org/D62090
llvm-svn: 362048
The libc++ typeinfo implementation is being improved to better
handle non-merged type names.
This patch takes advantage of that more correct behavior by delegating
to std::type_infos default operator== instead of doing pointer equality
ourselves.
However, libc++ still expects unique RTTI by default, and so we
should still fall back to strcmp when explicitly requested.
llvm-svn: 361916
This change is a consequence of the discussion in "RFC: Place libs in
Clang-dedicated directories", specifically the suggestion that
libunwind, libc++abi and libc++ shouldn't be using Clang resource
directory. Tools like clangd make this assumption, but this is
currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build.
This change addresses that by moving the output of these libraries to
lib/$target/c++ and include/c++ directories, leaving resource directory
only for compiler-rt runtimes and Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D59168
llvm-svn: 361432
When builing the hermetic static library, the compiler switch
-fvisibility-global-new-delete-hidden is necessary to get the new and
delete operator definitions made correctly. However, when those
definitions are not included in the library, then this switch does harm.
With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF
symbols makes it an error to leave them undefined or defined via dynamic
linking that should generate PLTs for -shared linking (lld makes this a
hard error even without -z defs). Though leaving the symbols undefined
would usually work in practice if the linker were to allow it (and the
user didn't pass -z defs), this actually indicates a real problem that
could bite some target configurations more subtly at runtime. For
example, x86-32 ELF -fpic code generation uses hidden visibility on
declarations in the caller's scope as a signal that the call will never
be resolved to a PLT entry and so doesn't have to meet the special ABI
requirements for PLT calls (setting %ebx). Since these functions might
actually be resolved to PLT entries at link time (we don't know what the
user is linking in when the hermetic library doesn't provide all the
symbols itself), it's not safe for the compiler to treat their
declarations at call sites as having hidden visibility.
Differential Revision: https://reviews.llvm.org/D61572
llvm-svn: 360004
This change introduces support for building libcxxabi. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.
We only support two stage build at the moment.
Differential Revision: https://reviews.llvm.org/D60372
llvm-svn: 359805
The threaded cxa guard test attempted to test multithreaded waiting
by lining up a bunch of threads at a held init lock and releasing them.
The test initially wanted each thread to observe the lock being held,
but some threads may arive too late.
This patch cleans up the test and relaxes the restrictions.
llvm-svn: 359785
The error is:
libcxxabi/src/cxa_guard_impl.h: In instantiation of ‘__cxxabiv1::{anonymous}::LibcppMutex __cxxabiv1::{anonymous}::GlobalStatic<__cxxabiv1::{anonymous}::LibcppMutex>::instance’:
libcxxabi/src/cxa_guard_impl.h:529:62: required from here
libcxxabi/src/cxa_guard_impl.h:510:23: error: ‘__cxxabiv1::{anonymous}::LibcppMutex __cxxabiv1::{anonymous}::GlobalStatic<__cxxabiv1::{anonymous}::LibcppMutex>::instance’ has incomplete type
_LIBCPP_SAFE_STATIC T GlobalStatic<T>::instance = {};
^
llvm-svn: 359175
This patch does three main things:
(1) It re-writes the cxa guard implementation to make it testable.
(2) Adds support for recursive init detection on non-apple platforms.
(3) It adds a futex based implementation.
The futex based implementation locks and notifies on a per-object basis, unlike the
current implementation which uses a global lock for all objects. Once this patch settles
I'll turn it on by default when supported.
llvm-svn: 359060
Summary:
Ensure we re-export __cxa_throw_bad_array_new_length and
__cxa_uncaught_exceptions from libc++, since they are now
provided by libc++abi.
Doing this allows us to stop linking explicitly against libc++abi in
the libc++abi tests, since libc++ re-exports all the necessary symbols.
However, there is one caveat to that. We don't want libc++ to re-export
__cxa_uncaught_exception (the singular form), since it's only provided
for backwards compatibility. Hence, for the single test where we check
this backwards compatibility, we explicitly link against libc++abi.
PR27405
PR22654
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60424
llvm-svn: 358690
On ARM the hand-rolled check causes a call to __aeabi_uidiv,
which we may not have a definition for.
Using the builtin avoids the generation of any library call.
llvm-svn: 358195
Summary:
The goal is to use a descriptive name for this feature, instead of just
using __arm__.
Reviewers: EricWF
Subscribers: javed.absar, kristof.beyls, christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60520
llvm-svn: 358106
This reverts commit r357944 and r357949.
These changes failed to account for the fact that
the guard object is under aligned for atomic operations
on 32 bit platforms (It's aligned to 4 bytes but we require 8).
llvm-svn: 357958
The read of the guard variable by the caller is atomic,
and doesn't happen under a mutex.
Our internal reads and writes were non-atomic, because they happened
under a mutex.
The writes should always be atomic since they can be observed outside
of the lock.
Making the reads atomic is not strictly necessary under the current
global mutex approach, but will be under implementations that use a
futex (which I plan to land shortly). However, they should add little
additional cost.
llvm-svn: 357944
This patch is a part of a series of patches to cleanup
our implementation of __cxa_acquire et al. No functionality
change was intended.
This patch does two primary things.
It introduces the GuardObject class to abstract the reading
and writing to the guard object. In future, it will be used
to ensure atomic accesses are used when needed.
It also introduces the GuardValue class used to represent
values of the guard object. It is an abstraction to access
and write to the various different bits of a guard.
llvm-svn: 357804
This patch is a part of a series of cleanups to cxa_guard.cpp.
It should introduce no functionality change.
This patch refactors the use of the global mutex and condvar into
a RAII lock guard class. This improves correctness (since unlocks can't
be forgotten). It also allows the unification of the non-threading and
threading implementations.
llvm-svn: 357669
This change is similar to r356150, with the same motivation. The
only difference is that the method used to merge libunwind.a and
libc++abi.a had to be changed to use the same approach as libc++
since we no longer produce object libraries that could be linked
together as we did before. We reuse the libc++ script for merging
archives to avoid duplication between the two projects.
Differential Revision: https://reviews.llvm.org/D60173
llvm-svn: 357635
This is on by default, since on many platforms and configurations
libc++abi.a gets statically linked into shared libraries and/or
PIE executables.
This change is a followup to https://reviews.llvm.org/D60005 which
allows us to default to PIC code, but disable this if needed (for
example on WebAssembly where PIC code its currently compatible with
static linking).
Differential Revision: https://reviews.llvm.org/D60049
llvm-svn: 357551
With the current WebAssembly backend, objects built with -fPIC are not
compatible with static linking. libc++abi was (mistakenly?) adding
-fPIC to the objects it was including in a static library.
IIUC this change should also mean the static build can be more efficient
on all platforms.
Differential Revision: https://reviews.llvm.org/D60005
llvm-svn: 357322
This change is a consequence of the discussion in "RFC: Place libs in
Clang-dedicated directories", specifically the suggestion that
libunwind, libc++abi and libc++ shouldn't be using Clang resource
directory. Tools like clangd make this assumption, but this is
currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build.
This change addresses that by moving the output of these libraries to
lib/<target> and include/ directories, leaving resource directory only
for compiler-rt runtimes and Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D59013
llvm-svn: 355665
This matters on OSX because static linking orders is also the order dyld
uses to search for libs (the default - Two-level namespace). If system
libs (including unwind lib) are specified before local unwind lib, local
unwind lib would never be picked up by dyld.
Before:
$ otool -L lib/libc++abi.dylib
@rpath/libc++abi.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
@rpath/libunwind.1.dylib (compatibility version 1.0.0, current version 1.0.0)
After:
$ otool -L lib/libc++abi.dylib
@rpath/libc++abi.1.dylib (compatibility version 1.0.0, current version 1.0.0)
@rpath/libunwind.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
Thanks to Yuanfang Chen for the patch.
Differential Revision: https://reviews.llvm.org/D57496
llvm-svn: 355241
This include doesn't seem to be needed for the standalone build (it's
not being used by libc++ build either), but introduces unnecessary
dependency because HandleOutOfTreeLLVM performs checks that require
a working C++ library. We shouldn't require a working C++ library to
build libc++abi or libc++ (it's what we're building after all).
Differential Revision: https://reviews.llvm.org/D58333
llvm-svn: 354284
This changes add_custom_libcxx to also build libcxxabi and merges
the two into a static and hermetic library.
There are multiple advantages:
1) The resulting libFuzzer doesn't expose C++ internals and looks
like a plain C library.
2) We don't have to manually link in libstdc++ to provide cxxabi.
3) The sanitizer tests cannot interfere with an installed version
of libc++.so in LD_LIBRARY_PATH.
Differential Revision: https://reviews.llvm.org/D58013
llvm-svn: 354212
We build libc++ and libc++abi with -nodefaultlibs, so -rtlib=compiler-rt
has no effect and results in an 'argument unused during compilation'
warning which breaks the build when using -Werror. We can therefore drop
-rtlib=compiler-rt without any functional change; note that the actual
compiler-rt linking is handled by HandleCompilerRT.
Differential Revision: https://reviews.llvm.org/D58084
llvm-svn: 353786
We're building tests with -nostdlib which means that we need to
explicitly include the builtins library. When using libgcc (default)
we can simply include -lgcc_s on the link line, but when using
compiler-rt builtins we need a complete path to the builtins library.
This path is already available in CMake as <PROJECT>_BUILTINS_LIBRARY,
so we just need to pass that path to lit and if config.compiler_rt is
true, link it to the test.
Prior to this patch, running tests when compiler-rt is being used as
the builtins library was broken as all tests would fail to link, but
with this change running tests when compiler-rt bultins library is
being used should be supported.
Differential Revision: https://reviews.llvm.org/D56701
llvm-svn: 353208
There are several changes:
- Don't stringify Pythonized bools (that's why we're Pythonizing them)
- Support specifying target and sysroot via CMake variables
- Use consistent spelling for --target, --sysroot, --gcc-toolchain
llvm-svn: 353137
CMake has a standard way of setting target triple, sysroot and external
toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and
CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into
corresponding --target=, --sysroot= and --gcc-toolchain= variables add
included appended to CMAKE_<LANG>_FLAGS.
libunwind, libc++abi, libc++ provides their own mechanism through
<PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN
variables. These are also passed to lit via lit.site.cfg, and lit config
uses these to set the corresponding compiler flags when building tessts.
This means that there are two different ways of setting target, sysroot
and toolchain, but only one is properly supported in lit. This change
extends CMake build for libunwind, libc++abi and libc++ to also support
the CMake variables in addition to project specific ones in lit.
Differential Revision: https://reviews.llvm.org/D57670
llvm-svn: 353084
When linking library dependencies, we shouldn't need to export linked
libraries to dependents. We should be explicit about this in
target_link_libraries, otherwise other targets that depend on these such
as sanitizers get repeated (and possibly even conflicting) dependencies.
Differential Revision: https://reviews.llvm.org/D57456
llvm-svn: 352688
When linking library dependencies, we shouldn't need to export linked
libraries to dependents. We should be explicit about this in
target_link_libraries, otherwise other targets that depend on these such
as sanitizers get repeated (and possibly even conflicting) dependencies.
Differential Revision: https://reviews.llvm.org/D57456
llvm-svn: 352654
This is useful when the static libunwind library is being linked into
shared libraries that may be used in with other shared libraries that
use different unwinder. We want to avoid avoid exporting libunwind
symbols in those cases. This achieved by a new CMake option which can be
enabled by libunwind vendors as needed.
The same CMake option has already been added to libc++ and libc++abi in
D55404 and D56026.
Differential Revision: https://reviews.llvm.org/D57107
llvm-svn: 352559
This fixes most references to the paths:
llvm.org/svn/
llvm.org/git/
llvm.org/viewvc/
github.com/llvm-mirror/
github.com/llvm-project/
reviews.llvm.org/diffusion/
to instead point to https://github.com/llvm/llvm-project.
This is *not* a trivial substitution, because additionally, all the
checkout instructions had to be migrated to instruct users on how to
use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of
checking out various projects into various subdirectories.
I've attempted to not change any scripts here, only documentation. The
scripts will have to be addressed separately.
Additionally, I've deleted one document which appeared to be outdated
and unneeded:
lldb/docs/building-with-debug-llvm.txt
Differential Revision: https://reviews.llvm.org/D57330
llvm-svn: 352514
Louis Dionne