When CMAKE_SYSROOT or CMAKE_FIND_ROOT_PATH is set, cmake
recommends setting CMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY
globally which means find_path() always prepends CMAKE_SYSROOT or
CMAKE_FIND_ROOT_PATH to all paths used in the search.
However, these find_path() invocations are looking for paths in
the libcxx and libunwind projects on the host system, not the
target system, which can be done by passing
NO_CMAKE_FIND_ROOT_PATH.
Differential Revision: https://reviews.llvm.org/D41623
llvm-svn: 323145
Summary:
Don't print, possibly erroneous, warning if
LIBCXXABI_INCLUDE_TESTS is false.
This patch fixes a problem introduced in r291367.
Differential Revision: https://reviews.llvm.org/D42229
llvm-svn: 322870
This patch updates libc++abi's HandleOutOfTreeLLVM.cmake to match
libc++'s -- and more importantly, to fix a bug where llvm-lit wasn't
found/created when libc++abi was built out-of-tree. This prevented
the test suite from running.
llvm-svn: 322768
Summary:
We want to automatically copy the appropriate mailing list
for review requests to the libc++abi repository.
For context, see the proposal and discussion here:
http://lists.llvm.org/pipermail/cfe-dev/2017-November/056032.html
Similar to D40500, I set up a new Diffusion repository with callsign
"CXXA" for libc++abi:
https://reviews.llvm.org/source/libcxxabi/
This explicitly updates libcxxabi's .arcconfig to point to the new
CXX repository in Diffusion, which will let us use Herald rule H268.
Reviewers: phosek, beanz, EricWF, compnerd
Reviewed By: phosek
Subscribers: cfe-commits, klimek, sammccall, dlj, bkramer
Differential Revision: https://reviews.llvm.org/D40501
llvm-svn: 319713
LLVM is gaining install-*-stripped targets to perform stripped installs,
and in order for this to be useful for install-distribution, all
potential distribution components should have stripped installation
targets. LLVM has a function to create these install targets, but since
we can't use LLVM CMake functions in libc++abi, let's do it manually.
Differential Revision: https://reviews.llvm.org/D40681
llvm-svn: 319499
object is sufficiently aligned.
r303175 annotated field unwindHeader of __cxa_exception with attribute
'aligned' to ensure the thrown object following the __cxa_exception
header was sufficiently aligned. This caused changes in the field
offsets of __cxa_exception relative to the start of the thrown object,
which was an ABI breaking change for some clients.
Instead of annotating field unwindHeader, this commit inserts extra
space before the header. This ensures the thrown object following the
header is sufficiently aligned without changing the field offsets, thus
avoiding any ABI breakages.
rdar://problem/25364625
rdar://problem/35556163
llvm-svn: 319123
This is useful in cases where we only build static library and
libc++abi.a is combined with libc++.a into a single archive in which
case we don't want to have libc++abi.a installed separately. The same
option is already provided by libcxx CMake build.
Differential Revision: https://reviews.llvm.org/D40194
llvm-svn: 318568
When using LLVM unwinder and static unwinder option is set, merge
libunwind and libc++abi objects into a single archive. libc++ already
supports merging libc++abi.a and libc++.a into a single archive; with
this change, it is possible to also include libunwind.a in the same
archive which is useful when doing static link and using libc++ as
a default C++ library and compiler-rt as a default runtime library.
Differential Revision: https://reviews.llvm.org/D39949
llvm-svn: 318563
compiler-rt recently added the __asan_handle_no_return() function that libc++abi
needs to use, however older versions of compiler-rt don't declare this interface
publicly and that breaks the libc++abi build.
This patch attempts to fix the issues by declaring the asan function explicitly,
so we don't depend on compiler-rt to provide the declaration.
llvm-svn: 313308
Summary:
compiler-rt recently added the `__asan_handle_no_return()` function that libc++abi needs to use, however older versions of compiler-rt don't provide this interface and that breaks the libc++abi build.
This patch attempts to fix the issues by using a macro to detect if `asan_interface.h` is new enough to provide the function.
See D37871
Reviewers: phosek, vitalybuka
Reviewed By: phosek, vitalybuka
Subscribers: dberris, cfe-commits
Differential Revision: https://reviews.llvm.org/D37872
llvm-svn: 313304
The ASan runtime on many systems intercepts cxa_throw just so it
can call asan_handle_no_return first. Some newer systems such as
Fuchsia don't use interceptors on standard library functions at all,
but instead use sanitizer-instrumented versions of the standard
libraries. When libc++abi is built with ASan, cxa_throw can just
call asan_handle_no_return itself so no interceptor is required.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D37229
llvm-svn: 313215
The ASan runtime on many systems intercepts cxa_throw just so it
can call asan_handle_no_return first. Some newer systems such as
Fuchsia don't use interceptors on standard library functions at all,
but instead use sanitizer-instrumented versions of the standard
libraries. When libc++abi is built with ASan, cxa_throw can just
call asan_handle_no_return itself so no interceptor is required.
This is a re-land of r311045, which has become safe after r311869
changed compiler-rt to declare __asan_handle_no_return.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D37229
llvm-svn: 312606
The ASan runtime on many systems intercepts cxa_throw just so it
can call asan_handle_no_return first. Some newer systems such as
Fuchsia don't use interceptors on standard library functions at all,
but instead use sanitizer-instrumented versions of the standard
libraries. When libc++abi is built with ASan, cxa_throw can just
call asan_handle_no_return itself so no interceptor is required.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D36599
llvm-svn: 311045
The demangler now demangles by producing an AST, then traverses that
AST to produce a demangled name. This is done for performance reasons,
now the demangler doesn't manuiplate std::strings, which hurt
performance and caused string operations to be inlined into the
parser, leading to large code size and stack usage.
Differential revision: https://reviews.llvm.org/D35159
llvm-svn: 309340
This patch removes the dependancy on libc++'s __refstring header,
which was only a header in the first place so that libc++abi could
build library code using it, and not because libc++ needed it in
the headers.
This patch allows libc++ to stop shipping <__refstring> publicaly
at the cost of duplicating it across projects. Ideally libc++abi
would always require the libc++ sources when building, but that's
a separate discussion I plan to start on the mailing lists shortly.
llvm-svn: 307748
This is going to be used by the runtime build in the multi-target
setup to allow using different install prefix for each target.
Differential Revision: https://reviews.llvm.org/D33761
llvm-svn: 307611
Rather than manually checking for support for the spelling of the C++
standard, indicate to CMake that we require that the compiler support
C++11 and that we compile without the GNU extensions. This simplifies
the flags handling in libc++abi itself by relying on CMake to translate
the flag and add it as appropriate.
llvm-svn: 305175
Use the POSITION_INDEPENDENT_CODE target property to indicate that we
should be building with -fPIC or the equivalent flag based on the
toolchain that we are using. This makes the check more portable and
simplifies the flags management. Because we don't want this setting to
propagate in the case of an in-tree build, set the property on the
targets we construct explicitly rather than setting
CMAKE_POSITION_INDEPENDENT_CODE to ON globally.
llvm-svn: 305174
Use the C++11 (formalised in C++17) tag to indicate a fallthrough in the
switch case. Silences a -Wimplicit-fallthrough warning with gcc:7
llvm-svn: 305173
Refactor cmake to remove dependence on LLVM's cmake modules.
This improves handling of cmake checks when cross compiling and brings
libcxxabi in line with libcxx and other project modules.
Differential revision: https://reviews.llvm.org/D33635
llvm-svn: 304374
As per r241993, libunwind_ext.h is not used anymore, and thus only the public libunwind includes are needed.
This eases distro packaging efforts and removes an unneeded requirement for out-of-tree building.
Reviewed as D33178
llvm-svn: 304359
The problem was that if base_name() was called from a context without
an actual base name, it could gulp up the entire string, which can
result in recursive duplications. The fix is to be more strict as to
what qualifies as a base name.
Differential revision: https://reviews.llvm.org/D33637
llvm-svn: 304113
Summary:
Previously if we parsed a constructor then we set parsed_ctor_dtor_cv
to true and never reseted it. This causes issue when a template argument
references a constructor (e.g. type of lambda defined inside a
constructor) as we will have the parsed_ctor_dtor_cv flag set what will
cause issues when parsing later arguments.
Reviewers: EricWF, compnerd
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33385
llvm-svn: 303737
The problem is that multiple types could have been parsed from parse_type(),
which the lamdba parameter parsing didn't handle.
Differential revision: https://reviews.llvm.org/D33368
llvm-svn: 303718
r276215 made a change to annotate _Unwind_Exception with attribute
"aligned" so that an exception object following field __cxa_exception
is sufficiently aligned. This fix hasn't been incorporated to unwind.h
on Darwin since it is an ABI breaking change.
Instead of annotating struct _Unwind_Exception with the attribute, this
commit annotates field unwindHeader of __cxa_exception. This ensures the
exception object is sufficiently aligned without breaking the ABI.
This recommits r302978 and r302981, which were reverted in r303016
because a libcxx test was failing on an AArch64 bot. I also modified the
libcxxabi test case to check the alignment of the pointer returned by
__cxa_allocate_exception rather than compiling the test with -O1 and
checking whether it segfaults.
rdar://problem/25364625
Differential Revision: https://reviews.llvm.org/D33030
llvm-svn: 303175
For ARM EHABI, _Unwind_Exception is an alias of _Unwind_Control_Block,
which is not aligned, so we shouldn't align unwindHeader either.
rdar://problem/25364625
llvm-svn: 302981
r276215 made a change to annotate _Unwind_Exception with attribute
"aligned" so that an exception object following field __cxa_exception
is sufficiently aligned. This fix hasn't been incorporated to unwind.h
on Darwin since it is an ABI breaking change.
Instead of annotating struct _Unwind_Exception with the attribute, this
commit annotates field unwindHeader of __cxa_exception. This ensures the
exception object is sufficiently aligned without breaking the ABI.
This recommits r302763 with fixes to RUN lines in the test case.
rdar://problem/25364625
Differential Revision: https://reviews.llvm.org/D33030
llvm-svn: 302978
r276215 made a change to annotate _Unwind_Exception with attribute
"aligned" so that an exception object following field __cxa_exception
is sufficiently aligned. This fix hasn't been incorporated to unwind.h
on Darwin since it is an ABI breaking change.
Instead of annotating struct _Unwind_Exception with the attribute, this
commit annotates field unwindHeader of __cxa_exception. This ensures the
exception object is sufficiently aligned without breaking the ABI.
rdar://problem/25364625
Differential Revision: https://reviews.llvm.org/D33030
llvm-svn: 302763
libc++abi can't depend on libc++, so disable extern templates in libc++
headers project-wide. This was previously done in cxa_demangle.cpp, but
I consider it more appropriate to do at the cmake level (since none of
libc++abi's source files can use libc++ extern templates).
I also think the _LIBCPP_NO_EXCEPTIONS in cxa_demangle.cpp is
suspicious, but I'm doing one thing at a time.
Differential Revision: https://reviews.llvm.org/D32329
llvm-svn: 302739
CMake has the problem with the single dash variant because of the
space, so use the double dash with equal sign version. These flag
need to be included in compile flags to propagate correctly. We also
don't have to pass the target triple when checking for compiler-rt
since that flag is already included in compile flags now.
Differential Revision: https://reviews.llvm.org/D32069
llvm-svn: 300418
Since libc++abi is built with -nodefaultlibs, we should be using this
option even for CMake checks to avoid any inconsistency and also to
avoid dependency on a working C++ standard library just for the setting
up the build itself. The implementation is largely similar to the one
used by libc++.
Differential Revision: https://reviews.llvm.org/D31639
llvm-svn: 299797
This test fails on ARM bare-metal targets because it assumes the Itanium ABI,
whereas EHABI requires the exception address to be 8-byte aligned.
I was a bit puzzled at first because this should've failed on the public
arm-linux builder too. I think the reason it passes there is because we don't
include libunwind headers in the include path when running the libcxxabi tests,
so the system unwind.h gets picked up.
Reviewers: rengolin, EricWF
Differential revision: https://reviews.llvm.org/D31178
llvm-svn: 299435
Summary: It's now completely empty, so we can remove it entirely.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31502
llvm-svn: 299129
This was originally there for the _POSIX_THREADS define, to detect the
presence of pthreads. That went away with the externalized threading
support, so the include can go away too.
config.h is now completely empty. A follow-up commit will remove it
entirely.
llvm-svn: 299087
This patch fully reformats fallback_malloc.cpp. Previously the test
was a mess of different styles and indentations. This made it very
hard to work in and read. Therefore I felt it was best to re-format
the whole thing.
Unfortuantly this means some history will be lost, but hopefully
much of it will still be accessible after ignoring whitespace changes.
llvm-svn: 296960
Summary:
In 32 bit builds on a 64 bit system `std::malloc` does not return correctly aligned memory. This leads to undefined behavior.
This patch switches to using `posix_memalign` to allocate correctly aligned memory instead.
Reviewers: mclow.lists, danalbert, jroelofs, compnerd
Reviewed By: compnerd
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25417
llvm-svn: 296952
Summary:
Currently both libc++ and libc++abi provide definitions for operator new/delete. However I believe this is incorrect and that one or the other should offer them.
This patch adds the CMake option `-DLIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS` which defaults to `OFF` unless otherwise specified. This means that by default
only libc++ provides the new/delete definitions.
Reviewers: mclow.lists, mehdi_amini, dexonsmith, beanz, jroelofs, danalbert, smeenai, rmaprath, mgorny
Reviewed By: mehdi_amini
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30517
llvm-svn: 296801
Summary:
Currently both libc++ and libc++abi provide definitions for new/delete. However libc++abi's definitions haven't been updated to include aligned new/delete or sized deallocation.
I don't see any reason why libc++abi shouldn't provide these newer overloads.
This patch copies libc++'s implementation of `new/delete` into libc++abi so that it's now up to date.
After applying this patch I plan to fix a longstanding bug where both libc++ and libc++abi provide definitions for new/delete.
Reviewers: mclow.lists, mehdi_amini, dexonsmith, danalbert, smeenai, rmaprath, jroelofs
Reviewed By: mehdi_amini
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30514
llvm-svn: 296787
This patch cleans up how libc++abi handles the definitions for new/delete.
It is in preperation for upcoming changes to fix how both libc++ and libc++abi
handle new/delete.
The primary changes in this patch are:
* Move the definitions for bad_array_length and bad_new_array_length
into stdlib_exception.cpp. This way stdlib_new_delete.cpp only
contains new/delete.
* Rename cxa_new_delete.cpp -> stdlib_new_delete.cpp for consistency
with other files.
* Add a FIXME regarding when stdlib_new_delete.cpp is actually compiled
as part of the dylib.
llvm-svn: 296715
Use the libc++abi visibility macros instead of pragmas or using
visibility attributes directly. Clean up redundant attributes on
definitions (where the declarations already have visibility attributes
applied, from either libc++ or libc++abi headers).
Introduce _LIBCXXABI_WEAK as a drive-by cleanup, which matches the
semantics of _LIBCPP_WEAK.
No functional change. Tested by building on Linux before and after this
change and verifying that the list of exported symbols is identical.
Differential Revision: https://reviews.llvm.org/D26949
llvm-svn: 296576
These tests embed calls to exceptions-related symbols from the abi library,
which are absent in the no-exceptions variant. The tests need to be marked
as unsupported for the no-exceptions configuration.
llvm-svn: 296344
Made a mistake in the condition typo because LIBCXXABI_BAREMETAL is always
defined, I should have been checking the contents to see if it's enabled.
Differential Revision: https://reviews.llvm.org/D30343
llvm-svn: 296146
We've been having issues with using libcxxabi and libunwind for baremetal
targets because fprintf is dependent on io functions, this patch disables calls
to fprintf when building for baremetal in release mode.
Differential Revision: https://reviews.llvm.org/D30339
llvm-svn: 296136
The libcxx/test/libcxx Python package has been moved into
libcxx/utils/libcxx in r294651, but libcxxabi's CMakeLists.txt still
looks for the old path.
Differential Revision: https://reviews.llvm.org/D30133
llvm-svn: 295540
When libcxxabi is built in LIBCXXABI_SILENT_TERMINATE mode, libcxx test suite reports
two failures:
std/depr/exception.unexpected/set.unexpected/get_unexpected.pass.cpp
std/depr/exception.unexpected/set.unexpected/set_unexpected.pass.cpp
This is because the default unexpected handler is set to std::abort instead of
std::terminate which these tests expect.
llvm-svn: 295175
When building as part of runtimes, there is no predefined order in
which the runtimes are loaded, so the targets from other projects
might not be available. We need to rely on HAVE_<name> variables
instead in that case.
Differential Revision: https://reviews.llvm.org/D29574
llvm-svn: 294552
When checking if the type is a r-value ref, we would not do a complete
check. This would result in us treating a trailing parameter reference
`&)` as a r-value ref, and improperly inject the cv qualifier on the
type. We now correctly demangle the type `KFvRmE` as a constant
function rather than a constant reference.
Fixes PR31741!
llvm-svn: 292973
Fix an off-by-one case which would destroy the final parameter in a
CV-qualified function type with a reference. We still get the CV
qualification incorrect, but at least we do not clobber the type name
any longer.
Partially fixes PR31741.
llvm-svn: 292963
Pending LIT changes are about to remove the REQUIRES-ANY keyword
in place of supporting boolean && and || within "REQUIRES". This
patch prepares libc++ for that change so that when applied
the bots don't lose their mind.
llvm-svn: 292906
This test contained an implicit conversion from nullptr to bool.
Clang warns about this but the test had supressed that warning.
However GCC diagnoses the same code as an error and requires
-fpermissive to accept it.
This patch fixes both the warning and the error by explicitly
converting the pointer to bool.
llvm-svn: 292638
The Itanium ABI [1] specifies that __cxa_demangle accept either:
1) symbol names, which start with "_Z"
2) type manglings, which do not start with "_Z"
r286788 erroneously assumes that it should only handle symbols, so this patch
reverts it and adds a counterexample to the testcase.
1: https://mentorembedded.github.io/cxx-abi/abi.html#demangler
Reviewers: zygoloid, EricWF
llvm-svn: 292418
Add LIBUNWIND_* directories to include path only if they were actually
found, in order to fix the CMake error. Both of the directories are
usually unnecessary since libcxxabi uses only the common part of
unwind.h that is supplied both by GCC and Clang.
Differential Revision: https://reviews.llvm.org/D25314
llvm-svn: 292018
This patch adjusts the out-of-tree CMake configuration so that
the stderr output is ignored when an old llvm-config is found
that doesn't support --cmakedir.
llvm-svn: 291993
The current std::terminate_handler pulls in some string code, some I/O
code, and more. Since it is automatically setup as the default, this
means that any trivial binary linking against libcxxabi will get this
extra bloat.
This patch allows disabling it as a build-time option, if you want to
avoid the extra bloat.
Patch by Tom Rybka!
Reviewers: EricWF
Subscribers: danalbert, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28497
llvm-svn: 291946
Use the new --cmakedir option to obtain LLVM_CMAKE_PATH straight from
llvm-config. Fallback to local reconstruction if llvm-config does not
support this option.
llvm-svn: 291506
+ Now that libcxxabi shares the same threading API as libcxx, a whole
chunk of code in src/config.h is made redundant (I missed this earlier).
+ r291275 split off the externalized-thread-api libcxx configuration from the
external-thread-library libcxx configuration. libcxxabi should follow the
same approach.
llvm-svn: 291440
Tests targets will now be enabled by default when building libcxxabi out of tree
(unless turned off with LIBCXXABI_INCLUDE_TESTS=OFF).
Differential Revision: https://reviews.llvm.org/D28450
llvm-svn: 291378
Use an `extern "C" { }` block around the definition rather than doing
the inline definition. This avoids a GCC warning about a declaration
being extern and having a definition. NFC.
llvm-svn: 290937
r281179 Introduced an externally threaded variant of the libc++ library. This
patch adds support for a similar library variant for libc++abi.
Differential revision: https://reviews.llvm.org/D27575
Reviewers: EricWF
llvm-svn: 290888
The macOS thread-local variable finalizer routines do not handle the
case where a termination function registers another termination function
correctly, causing this test to fail. I've filed a radar for this;
mark the test XFAIL in the meantime. See [1] for more details.
[1] http://lists.llvm.org/pipermail/cfe-dev/2016-November/051376.html
Differential Revision: https://reviews.llvm.org/D27434
llvm-svn: 289513
It's useful to be able to disable visibility annotations entirely; for
example, if we're building libc++abi static to include in another library,
and we don't want any libc++abi functions getting exported out of that
library. This is a generalization of _LIBCXXABI_DISABLE_DLL_IMPORT_EXPORT.
Differential Revision: https://reviews.llvm.org/D26950
llvm-svn: 288692
Sink the Db initialization into the structure rather than out-of-line at the
declaration size. This just makes it easier to see what initialization is being
performed. NFC.
llvm-svn: 287364
The block invocation function uses an extension where the prefix is ___Z
as opposed to _Z. This should make the tests pass again.
Disable a negative test which was testing a crasher. The symbol being
demangled is not a valid mangled symbol and will return a nullptr.
Adjust the type info decoding test to be a valid symbol name.
llvm-svn: 286793
Ensure that we have a mangled symbol before attempting to demangle it. We would
previously treat any input as a mangled symbol rather than checking that the
symbol has the initial C++ Itanium v3 mangling prefix of `_Z`. This changes the
behaviour from the previous case which would undecorate `f` to `float` rather
than nullptr as it should.
Unfortunately, we do not have any negative testing for the demangler.
llvm-svn: 286788
GCC 4.7 or newer emits 0x90 (indirect | pcrel) as the ttype encoding.
This would hit an assertion in cxa_personality.cpp. This commit fixes
the problem by relaxing the assertion.
llvm-svn: 286760
This commit fixes libc++abi build when LLVM unwinder (libunwind_llvm) is
not enabled.
This commit fixes the problem by removing "LLVM_NATIVE_ARCH MATCHES ARM"
from CMakeLists.txt so that LIBCXXABI_USE_LLVM_UNWINDER will only be
defined when LLVM unwinder is enabled.
We need LIBCXXABI_USE_LLVM_UNWINDER becase there is a subtle difference
between the unwinder from libgcc and the one from libunwind_llvm. For
the unwinder from libgcc, we have to initialize register r12 with the
address of _Unwind_Control_Block; otherwise,
_Unwind_GetLanguageSpecificData() and _Unwind_GetRegionStart() won't
work properly. Consequently, there is an extra _Unwind_SetGR() when
LLVM unwinder is disabled. Check cxa_personality.cpp for details.
llvm-svn: 286759
The runtimes subdir is the new location for runtimes, we should
include it when looking for libcxx and libunwind headers.
Differential Revision: https://reviews.llvm.org/D26362
llvm-svn: 286614
The runtimes subdir is the new location for runtimes, we should
include it when looking for libcxx and libunwind headers.
Differential Revision: https://reviews.llvm.org/D26362
llvm-svn: 286332
Summary:
Some changes are made to cmake, especially the addition of a new
LLVM_ENABLE_PROJECTS option that makes the build system aware of
the monorepo directory structure.
Also a new script is added in llvm/utils/git-svn/. When present in
the $PATH, it enables a `git llvm` command. It is providing at this
point only the ability to push from the git monorepo: `git llvm push`.
It is intended to evolves with more features, for instance I plan on
features like `git llvm show r284955` to help working with sequential
revision numbers.
The push feature is taken from Justin Lebar's script available here:
https://github.com/jlebar/llvm-repo-tools/
Reviewers: jlebar
Subscribers: mgorny, modocache, llvm-commits
Differential Revision: https://reviews.llvm.org/D26334
llvm-svn: 286123
This patch refactors all pthread uses of libc++abi into a separate API. This
is the first step towards supporting an externlly-threaded libc++abi library.
I've followed the conventions already used in the libc++ library for the same
purpose.
Patch from: Saleem Abdulrasool and Asiri Rathnayake
Reviewed by: compnerd, EricWF
Differential revisions:
https://reviews.llvm.org/D18482 (original)
https://reviews.llvm.org/D24864 (final)
llvm-svn: 284128
Throwing an exception for the first time may lead to call calloc to
allocate memory for __cxa_eh_globals. If the memory pool is exhausted
at that moment, it results in abnormal termination of the program.
This patch addresses the issue by using fallback_malloc in that case.
In this revision, some restrictions were added into the test to not
run it in unsuitable environments.
Differential Revision: https://reviews.llvm.org/D17815
llvm-svn: 283531
The cmake files install directory has been changed to
${prefix}/lib/cmake/llvm since r259821. Searching cmake modules in
${prefix}/share/llvm/cmake will result in fatal errors.
This commit fixes the out-of-tree build by changing the CMake module
search path to: "$(llvm-config --obj-root)/lib/cmake/llvm"
llvm-svn: 283100
Throwing an exception for the first time may lead to call calloc to
allocate memory for __cxa_eh_globals. If the memory pool is exhausted
at that moment, it results in abnormal termination of the program.
This patch addresses the issue by using fallback_malloc in that case.
Differential Revision: https://reviews.llvm.org/D17815
llvm-svn: 282692
`__declspec(dllexport)` and `__declspec(dllimport)` should only be used
when building libc++abi as a DLL, but that's the more common use case,
so default to adding the annotations and add an option to opt out.
Similar to r282449, which made the corresponding change for libc++.
Differential Revision: https://reviews.llvm.org/D24945
llvm-svn: 282470
These data and text symbols were missing annotations for building with hidden
visibility. As we do not currently enable hidden visibility by default, this is
a NFC for the buildbots.
llvm-svn: 282300
is_initialized is only used in the no threads case or if on non ARM Apple
targets. Use the preprocessor to remove the function otherwise. NFC.
llvm-svn: 280286
Summary: This patch adds a check for if -std=c++11 is a supported flag, and adds it to CMAKE_CXX_FLAGS if it is supported.
Reviewers: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24007
llvm-svn: 280021
This patch (and commit summary) mirror r279675 by Chris B which was applied
to libc++ but not libc++abi.
Summary:
The point of this patch is to have a consistent convention for naming build,
check and install targets so that the targets can be constructed from the
project name.
This change renames a bunch of CMake components and targets from libcxxabi to
cxxabi. For each renamed target I've added a convenience target that matches
the old target name and depends on the new target. This will preserve function
of the old targets so that the change doesn't break the world. We can evaluate
if it is worth removing the extra targets later.
llvm-svn: 279938
This patch applies changes similar to those in r279515 to libc++abi.
Summary of changes in this patch:
* Renamed variable LLVM_CONFIG -> LLVM_CONFIG_PATH
* Renamed variable LIBCXXABI_BUILT_STANDALONE -> LIBCXXABI_STANDALONE_BUILD
* Add an include of AddLLVM in the tests subdirectory for add_lit_testsuite.
llvm-svn: 279936
When we're running tests under ASAN or MSAN, they're compiled with -O1, which
enables tail call elimination. This causes backtrace_test to fail: the compiler
performs tail call elimination for call3_nothrow, but it can't for call3_throw,
leading to a mismatched frame count. Disable tail call elimination (and
inlining, just to be explicit) to avoid this.
Patch by Shoaib Meenai!
llvm-svn: 279935
When using libunwind and not building as standalone project, we
can directly depend on the unwind library target.
Differential Revision: https://reviews.llvm.org/D23289
llvm-svn: 278169
When using libunwind and not building as standalone project, we
need to add LLVM library directory to the list of linker directories
to ensure it can find libunwind dependency.
Differential Revision: https://reviews.llvm.org/D23287
llvm-svn: 278076
When libcxxabi is being built standalone, unwind dependency is not
available, so do not use it even when LLVM unwinder is being
requested.
Differential Revision: https://reviews.llvm.org/D23228
llvm-svn: 278058
pointer-to-member type, produce a null value of the right type.
This fixes a bug where throwing an exception of type nullptr_t and catching it
as a pointer-to-member would not guarantee to produce a null value in the catch
handler. The fix is pretty simple: we statically allocate a constant null
pointer-to-data-member representation and a constant null
pointer-to-member-function representation, and produce the address of the
relevant value as the adjusted pointer for the exception.
llvm-svn: 276016
Add an option to opt into compiler-rt instead of libgcc. This option defaults
to OFF to avoid a behaviour change. It is not possible to mix and match
different runtime libraries. Disabling this requires that libc++ is built
accordingly. This knob is particularly useful for targets that are GCC by
default (i.e. Linux).
llvm-svn: 275505
Summary:
This patch fixes -Wreorder warnings on test classes with virtual bases. Since the compiler is performing the reordering anyway this change *should* have NFC.
However the test notes that it is checking that "virtual base classes work properly". Since initialization order is clearly part of correctness I want to confirm that this wasn't an intentional mistake.
Reviewers: mclow.lists, howard.hinnant
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21396
llvm-svn: 272821
This patch breaks the ABI on linux when libc++abi.a is statically linked into
libc++.so. Certain libc++ symbols get exported from libc++abi.a as hidden
and therefore they also get hidden in libc++.so.
The symbols is question are:
* _ZNKSt3__121__basic_string_commonILb1EE20__throw_out_of_rangeEv
* _ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv
* _ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv
I imagine we just need to fix the visibility for these symbols in the libc++
headers but I'm reverting the patch until it's sorted.
llvm-svn: 271500
Summary:
This patch changes the libc++abi CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including `config-ix.cmake`.
Since these flags can affect things like `check_library_exists([...])` they needed to be added before the tests are performed.
Additionally this patch adds `LIBCXXABI_BUILD_32_BITS` which defaults to `LLVM_BUILD_32_BITS`.
This patch fixes:
https://llvm.org/bugs/show_bug.cgi?id=27950https://llvm.org/bugs/show_bug.cgi?id=27959
Reviewers: danalbert, jroelofs, bcraig, compnerd, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20886
llvm-svn: 271470
Currently there is only support for a -fno-exceptions libc++ build. This is
problematic for functions such as std::terminate() which are defined in
libc++abi and using any of those functions throws away most of the benefits
of using -fno-exceptions (code-size). This patch introduces a -fno-exceptions
libc++abi build to address this issue.
This new variant of libc++abi cannot be linked against any with-exceptions
code as some symbols necessary for handling exceptions are missing in this
library.
Differential revision: http://reviews.llvm.org/D20677
Reviewers: EricWF, mclow.lists, bcraig
llvm-svn: 271267
Enable building libc++abi with hidden visibility by default. The ABI mandated
interfaces (and a few extra) are already set up to be externally visible. This
allows us to ensure that any implementation details are not leaked.
llvm-svn: 270816
When building libcxxabi in tree (i.e. in llvm/projects/libcxxabi,
along with llvm/projects/libcxx), libcxx's config_site.in doesn't
get created in a timely manner. This means that any configuration
that is normally set in libcxx's config_site.in needs to be
duplicated in libcxxabi to successfully build libcxxabi. This patch
does exactly that for the _LIBCPP_HAS_THREAD_API_PTHREAD
preprocessor define.
http://reviews.llvm.org/D20574
llvm-svn: 270732
This change leverages framework changes made in libcxx. See those changes for
more details. (http://reviews.llvm.org/D16544)
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.
http://reviews.llvm.org/D16545
llvm-svn: 266729
Prior to this patch, setting LIBCXXABI_LIBDIR_SUFFIX would confuse the
check-libcxxabi target. libc++abi.* would get output to lib instead of
lib${LIBCXXABI_LIBDIR_SUFFIX}, but the tests would look in the suffixed
directory.
Now, we match what libcxx does, and set the CMAKE_*_OUTPUT_DIRECTORY to the
LIBRARY_DIR.
http://reviews.llvm.org/D17410
llvm-svn: 266611
The feature check is already in place when building the library but wasn't
honored for the tests.
Differential Revision: http://reviews.llvm.org/D18205
llvm-svn: 263699
This test has a lot of classes with large amounts of manually inserted padding in them, presumably to prevent various optimizations. The test then creates lots of these objects on the stack. On embedded targets, this was usually enough to overflow the stack.
I moved the objects to global / namespace scope. Since the tests are each in their own namespace, there should be no cross-test conflicts.
llvm-svn: 262717
libcxxabi uses the C99 library's %a format specifier to turn a floating
point value into a hexadecimal string representation. The %a format
specifier is rather loosely defined in the C spec though, and some C
libraries emit a different (but valid) string for a given floating
point value. In particular, the C spec only requires that there is a
single, non-zero hexadecimal digit on the left of the decimal point.
Given that constraint, there are typically four different valid
representations of a floating point number. I have updated the test to
accept any of the valid representations for demangled floating
point literals.
llvm-svn: 258311
This patch re-commits r256322 and r256323. They were reverted due to a OS X
test failure. The test failure has been fixed by libc++ commit r258217.
This patch also adds some additional tests.
llvm-svn: 258249
This patch re-commits r256322 and r256323. They were reverted due to a OS X
test failure. The test failure has been fixed by libc++ commit r258217.
This patch also adds some additional tests.
llvm-svn: 258222
This commit adds SHF_ALLOC and SHF_EXECINSTR section flags to
`.text.__cxa_end_cleanup` section. This fixes a link error when we are
using integrated-as and `ld.gold` (with `-Wl,--gc-sections` and
`-Wl,--fatal-warnings`.)
Detailed Explanation:
1. There might be some problem with LLVM integrated-as. It is not
emitting any section flags for text sections. (This will be fixed in
an independent commit.)
2. `ld.gold` will skip the external symbols in the section without
SHF_ALLOC. This is the reason why `.text.__cxa_end_cleanup_impl`
section is discarded even though it is referenced by
`__cxa_end_cleanup()`.
This commit workaround the problem by specifying the section flags
explicitly.
Fix http://llvm.org/PR21292
llvm-svn: 256241
Summary:
libgcc_eh.a cannot be used when building libc++abi as a shared library (the default configuration). See this post for some more discussion: https://gcc.gnu.org/ml/gcc/2012-03/msg00104.html
This patch reverts back to using libgcc_s when linking libc++abi.so.
Reviewers: danalbert, chandlerc, mclow.lists, ismail, compnerd
Subscribers: vkalintiris, cfe-commits
Differential Revision: http://reviews.llvm.org/D15440
llvm-svn: 255559
Mark functions and types with the appropriate visibility. This is particularly
useful for environments which explicitly indicate origin of functions (Windows).
This aids in generating libc++abi as a DSO which exposes only the public
interfaces.
llvm-svn: 254691
Use `__builtin_offsetof` in place of `offsetof`. Certain environments provide a
macro definition of `offsetof` which may end up causing issues. This was
observed on Windows. Use `__builtin_offsetof` to ensure correct evaluation
everywhere. NFC.
llvm-svn: 253435
libstdc++ needs a few typedefs in malloc_alloc. MSVC's STL needs rebind(),
construct(), destroy(). MSVC2013 also has no snprintf, but it exists in 2015.
llvm-svn: 248129
When using SjLj EH, do not use __builtin_eh_return_regno, map directly to the
ID. This would work on some targets, particularly those where the non-SjLj EH
personality used the same register mapping (0 -> 0, 1 -> 1). However, this is
not guaranteed. Avoiding the use of the builtin enables the use of libc++ with
SjLj EH on all targets.
llvm-svn: 248108
Summary:
Currently you can't install libc++abi from within the LLVM tree without installing all of LLVM. This patch adds an install rule for libc++abi.
Reviewers: danalbert, compnerd, rengolin, beanz
Subscribers: martell, beanz, jroelofs, cfe-commits
Differential Revision: http://reviews.llvm.org/D11682
llvm-svn: 245461
Currently, the tests assume the system compiler is the one we want
to test, but if we build libcxxabi together with LLVM+Clang, it'll
get the wrong compiler.
This patch allows us to test if we have clang++ in our /bin directory,
and if so, use it.
llvm-svn: 243752
Summary:
Patch by Nitesh Jain and Jaydeep Patil with a small revision to use ABIs rather
than Architecture Revisions (which currently imply particular ABIs).
Fixes test_demangle.pass.cpp (PR24149).
Subscribers: mclow.lists, jaydeep, nitesh.jain, hans, cfe-commits
Differential Revision: http://reviews.llvm.org/D11483
llvm-svn: 243645
Summary:
backtrace_test.pass.cpp depends on unwind tables. These are generated by
-funwind-tables which is the default for x86 but not for other targets.
Thanks to Nitesh Jain for helping to narrow this down.
Fixes PR24148
Reviewers: jroelofs
Subscribers: cfe-commits, jroelofs, llvm-commits, hans
Differential Revision: http://reviews.llvm.org/D11529
llvm-svn: 243296
This silences some conversion warnings from GCC 4.9.2. Simply casting the RHS
doesn't seem to be sufficient to silence the warning. Convert the operation
equal operator usage to calculation and assignment.
llvm-svn: 238945
As a step to fix libunwind unw_step(), a new function
__gnu_unwind_frame() has been introduced to libunwind, and it is
required to use this function so that some libunwind internal data
structure can be updated properly.
llvm-svn: 238561
So cmake will throw error "include_directories given empty-string as include directory".
Use other variable name for the include path and do not find the default libunwind.h in the system path.
http://reviews.llvm.org/D9641
Patch by Jingyi Wei!
llvm-svn: 236936
Function pointers and member function pointers cannot be converted to void*.
libc++abi incorrectly allows this conversion for function pointers.
Review URL: http://reviews.llvm.org/D8811
llvm-svn: 236299
This papers over a layering violation currently between libc++abi and libunwind.
It reaches into the sources to get the declaration of an ABI defined function.
This should allow the ARM buildbot to continue building libc++abi again.
llvm-svn: 235965
Attempting to default the option to ON for ARM doesnt seem to work. Force the
check lower and perform the check at the two sites that matter: the CPPFLAGS
definition and the header search path setup.
llvm-svn: 235964
libc++abi uses EHABI extensions, which are only part of the LLVM unwinder. When
targeting ARM by default, enable the use of the LLVM unwinder. Hopefully this
will fix the ARM native bot
llvm-svn: 235904
The externC variable was set but unused. This constantly flagged a warning from
gcc. Replace it with a comment until such a time that we need it.
llvm-svn: 235830
Cleans up the -Wundef warning caused by the use of the __LITTLE_ENDIAN__ macro.
Instead use `__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__`. `__BYTE_ORDER__` is
defined by GCC since 4.2 and by clang. This avoids the undef case where a macro
may be undefined. This has previously caught real errors in libunwind.
llvm-svn: 235828
This removes the libunwind build infrastructure as libunwind is gaining its own
CMakeLists.txt. The removal must occur first due to the multiple definitions of
the same target.
llvm-svn: 235794
Summary:
I accidentally implemented the 4.11 [conv.mem] conversions for libc++abi in a recent patch. @majnemer pointed out that 5.13 [except.handle] only allows the pointer conversions in 4.10 and not those is 4.11. This patch no longer allows the following example code:
```c++
struct A {};
struct B : public A {};
int main() {
try {
throw (int A::*)0;
} catch (int B::*) {
// exception caught here.
}
}
```
Reviewers: mclow.lists, jroelofs, majnemer
Reviewed By: majnemer
Subscribers: majnemer, cfe-commits
Differential Revision: http://reviews.llvm.org/D8845
llvm-svn: 234254
Summary:
Currently there are bugs in out detection of multi-level pointer conversions and pointer to member conversions. This patch fixes the following issues.
* Allow multi-level pointers with different nested qualifiers.
* Allow multi-level mixed pointers to objects and pointers to members with different nested qualifiers.
* Allow conversions from `int Base::*` to `int Derived::*` but only for non-nested pointers.
There is still some work that needs to be done to clean this patch up but I want to get some input on it.
Open questions:
* Does `__pointer_to_member_type_info::can_catch(...)` need to adjust the pointer if a base to derived conversion is performed?
Reviewers: danalbert, compnerd, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8758
llvm-svn: 233984
The unwinder now works on CloudABI. All exception-related libc++ tests
now pass.
This change was actually part of D8169, which also adds support for
FreeBSD. That, however, still requires some more polishing.
llvm-svn: 233676
There is some debugging code in cxa_demangle.cpp that prints messages on
stdout. In general this is not safe, as the program itself may use
stdout to write its output. Change this code to write to stderr.
Differential Revision: http://reviews.llvm.org/D8167
llvm-svn: 232716
Summary: This patch fixes a bug in `readEncodedPointer()` where it would read from memory that was not suitably aligned. This patch fixes it by using memcpy.
Reviewers: danalbert, echristo, compnerd, mclow.lists
Reviewed By: compnerd, mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8179
llvm-svn: 231839
These are also part of the Unwind interfaces. However, their implementation is
different in EHABI vs frame tables based exception handling. Always provide a
definition. This partially undoes a movement change from earlier to make the
handling a bit simpler rather than grouping the two implementations together.
llvm-svn: 231690
These interfaces are not zero cost related, but rather generic unwind APIs used
by consumers of the Unwind library. Always provide the definition as they are
needed for both Zero Cost and Frame Table based implementations.
llvm-svn: 231666
Linux/GNU on AArch64 EH ABI Level III is implemented using exception frame
tables as defined in LSB II.11.6. The exception frame tables use the DWARF
Exception Header Encoding as described in LSB II.11.5.1. We already defined the
appropriate definition _LIBUNWIND_SUPPORT_DWARF_UNWIND to enable this.
llvm-svn: 231580
AArch64 uses // as the comment character (although, Darwin uses ;). However,
since we are using the C preprocessor on these files, // can be used as the
comment character across the board.
Tweak the platform guard to recognise __aarch64__ as well as __arm64__ for the
platform identifier.
llvm-svn: 231578
- GCC doesn't support #pragma mark, only Apple GCC and clang. Wrap the pragma mark's in #if 0 to make gcc ignore them but xcode still see them.
- Wrap a bunch of "#pragma clang" lines in #ifdef __clang__.
- Pacify gcc's -Wparenthesis in a case where it's quite reasonable.
llvm-svn: 231344
Summary:
This patch builds both static and shared versions of libc++abi by default. It adds/repurposes the following cmake options:
* `LIBCXXABI_ENABLE_SHARED`: Enable/disable building the shared library. (Previously using `OFF` would build the static library instead)
* `LIBCXXABI_ENABLE_STATIC`: Enable/disable building the static library.
This patch also re-purposes the CMake target `cxxabi` to be a meta-target for `cxxabi_shared` and `cxxabi_static`. This could potentially break other builds that depend on `cxxabi` being a library target. We will need to apply a patch to libc++'s CMake before committing this change.
Running the tests is still only supported when the shared version is built. Support for running the tests against the static library will come in another patch.
Reviewers: jroelofs, mclow.lists, danalbert, compnerd
Reviewed By: danalbert, compnerd
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8013
llvm-svn: 231075
The support for the LSB eh_frame_hdr extension was overzealous in trying to
include headers. Be more careful to permit building on Darwin.
llvm-svn: 230837
This improves the performance of unwinding on DWARF based targets. The
32-bit x86 support for scanning the full eh_frame
(CFI_Parser::findFDE) apparently does not work (at least not on
Linux). Since the eh_frame_hdr code delegates to that, this still
doesn't work for x86 Linux, but it has been tested on x86_64 Linux and
aarch64 Android.
llvm-svn: 230802
TODO: The iwmmx register save & restore functions still need the same treatment.
I didn't do that in this patch because the integrated assembler has a bug
where it refuses to build them on -march=armv6-m, even with
.march armv5t
.arm
in front of those functions.
This should fix PR22384.
http://reviews.llvm.org/D7258
llvm-svn: 230360
Adding just -fno-exceptions breaks libunwind in quite mysterious way
when it's there, but exception handling doesn't work because of dummy
unwind tables.
Also as using exceptions implies references to symbols defined in
libcxx, abort build of libcxxabi as shared library if we have to keep
exceptions (when compiler supports -fno-exceptions, but not
-funwind-tables; one example would be a cross-compiler, in which case
testing for -funwind-tables flag by CMake actually requires libunwind to
be available before it's built).
llvm-svn: 229427
It seems that the remote unwinder is entirely unused at this moment.
unw_local_addr_space was referencing sThisAddressSpace which use to be a static
in global namespace. It has since then become a member variable of
LocalAddressSpace. Update this definition and always export it (needed to
implement unw_get_proc_info_by_ip for ARM).
llvm-svn: 229133
The statically allocated strings have a fixed size which can be computed using
the sizeof operator rather than duplicating the allocation size which can drift.
NFC.
llvm-svn: 229126
Instead of bzero(), we can simply use memset(). The strcpy() calls are
unneeded, as we can simply keep track of a pointer to the constant
strings we are copying.
Reviewed by: Jonathan Roelofs
llvm-svn: 229074
Convert the register saving code to use an explicit memcpy rather than the
implicit memcpy from the assignment. This avoids warnings from -Wcast-qual on
GCC and makes the code more explicit. Furthermore, use sizeof to calculate the
offsets rather than adding magic numbers, improving legibility of the code.
NFC.
llvm-svn: 228904
Ideally, we would do something like inline __declspec(dllexport) to ensure that
the symbol was inlined within libunwind as well as emitted into the final DSO.
This simply moves the definition out of the header to ensure that the *public*
interfaces are defined and exported into the final DSO.
This change also has "gratuitous" code movement so that the EHABI and generic
implementations are co-located making it easier to find them.
The movement from the header has one minor change introduced into the code:
additional tracing to mirror the behaviour of the non-EHABI interfaces.
llvm-svn: 228903
This is a slightly convoluted workaround. GCC does not support the
__has_feature extension of clang, and this results in some issues with
static_asserts. config.h defines static_assert as a macro with a C-specific
trickery. This then propagates into the C++ headers included after config.h,
which are used with C++11 mode, enabling constexpr constructors. The macro'ed
static_assert does not get treated as the static_assert builtin, and will cause
an error due to a non-empty constexpr constructor. Tweaking the include order
permits the use of libc++ headers to build libunwind with GCC on Linux.
llvm-svn: 228809
Mark that the functions always return or abort if the register class is
unhandled. Avoid placing the abort in the switch to permit -Wswitch-cover to
catch missing values.
llvm-svn: 228808
gcc still defaults to C89 which does not support BCPL style comments. This
splits up the sources list in CMakeLists and selectively adds compile flags for
using C99 which avoids a number of warnings in -Wpedantic mode. NFC.
llvm-svn: 228665
The unified register management interfaces had multiple naked macros for
conditional logic. This cleans them up to use the defined() form, avoiding
-Wundef warnings. NFC.
llvm-svn: 228663
Move the placement delete into the base class. This permits the proper emission
of the virtual destructor in UnwindCursor by using the class specific placement
delete instead of the normal single element ::operator delete. With this patch,
we can finally build libunwind as a DSO without a runtime dependency on
libc++/libc++abi.
llvm-svn: 228436
Convert all pure virtual functions in the UnwindCursor with implementations that
abort. This is effectively manually replicating the current behaviour, whilst
removing the compiler generated calls to __cxa_pure_virtual, which will abort at
runtime with a message indicating that a pure virtual call was made.
The whitespace changes are the result of executing clang-format over the changed
region.
llvm-svn: 228423
RTTI and exceptions are not needed for the unwinder, the use of C++ there is for
very specific cases, and does not require dynamic_cast nor does it use
exceptions. This avoids unnecessary references to type information being
emitted.
llvm-svn: 228408
This reverts commit 4963ea3107a2fdfae21f7806896905f20b21ff0d.
This change was wrong. The parameter type is sugared via a typedef. The errors
generated may have been due to a different root cause, and should be fixed
through the recent series of changes.
llvm-svn: 228365
Summary:
The inclusion of Unwind-EHABI.h was insufficiently guarded
(LIBCXXABI_ARM_EHABI was beign checked without ever being defined).
Move the check into the header file itself, add the check to the
source file, and clean up the existing checks.
LIBCXXABI_ARM_EHABI didn't have a canonical defintion; it was
duplicated across cxxabi.h, libunwind.h, and unwind.h. Move the
definition into __cxxabi_config.h and clean up the old cruft (note: we
will have to ship this header).
There are also a few drive-by formatting/whitespace cleanups.
Reviewers: jroelofs, thakis, compnerd
Reviewed By: compnerd
Subscribers: compnerd, aemerson, cfe-commits
Differential Revision: http://reviews.llvm.org/D7419
llvm-svn: 228363
EHABI related typedef sugar is gated via LIBCXXABI_ARM_EHABI which did not
protect the EHABI header. This would cause declarations to be emitted on
non-EHABI targets, resulting in errors. This permits compilation on Darwin.
llvm-svn: 228359
config.h:53:7: warning 'FOR_DYLD' is not defined, evaluates to 0 [-Wundef]
Unwind_AppleExtras.cpp:44:5: warning '__arm__' is not defined, evaluates to 0 [-Wundef]
Unwind_AppleExtras.cpp:60:7: warning '__arm64__' is not defined, evaluates to 0 [-Wundef]
Unwind_AppleExtras.cpp:186:6: warning 'FOR_DYLD' is not defined, evaluates to 0 [-Wundef]
Use defined(macro) which should be equivalent in these cases, silencing -Wundef
warnings. NFC.
llvm-svn: 228358
Explicitly cast to uintptr_t before casting to a 32-bit value. Because this
code path is meant to be used in a 32-bit address space, this truncation should
be safe.
Unwind-EHABI.h:25:12: error: cast from pointer to smaller type 'uint32_t' (aka 'unsigned int') loses information
llvm-svn: 228357
The problem that caused the need for http://reviews.llvm.org/D7419 was
caused by testing the value of something that was undefined. This
should prevent that in the future.
llvm-svn: 228257
Summary:
The main section of this patch teaches CMake a new option `LIBCXXABI_LIBCXX_PATH` that specifies the path to the libcxx source root. This information is passed to lit so that it can better find libc++'s python module. `LIBCXXABI_LIBCXX_PATH` is also used to help find the libc++ headers.
The rest of this patch is misc cleanup, mostly to make pep8 and pylint happy.
I've also copied libc++'s .gitignore into libc++abi.
Reviewers: jroelofs, danalbert
Reviewed By: danalbert
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7130
llvm-svn: 226855
Without -funwind-tables, the compiler won't generate the unwinding
table for these C functions. However, the functions in libunwind,
such as `_Unwind_Backtrace()`, WILL unwind stack to get the backtrace.
llvm-svn: 226823
If libcxxabi is compiled as a shared library, and the
executable references the user-defined personality routines
(e.g. __gxx_personality_v0), then the pointer comparison in
Unwind-EHABI.cpp won't work. This is due to the fact that
the PREL31 will point to the PLT stubs for the personality
routines (in the executable), while the __gxx_personality_v0
symbol reference is yet another (different) PLT stub (in the
libunwind.)
This will cause _Unwind_Backtrace() stops to unwind the frame
whenever it reaches __gxx_personality_v0(). This CL fix the
problem by calling the user-defined personality routines
with an undocumented API for force unwinding.
llvm-svn: 226822
This CL adds a new compilation flags LIBCXXABI_USE_LLVM_UNWINDER
to specify whether the LLVM unwinder is enabled. Besides, all
unwinder-specific code are guarded with this definition.
Now, libc++abi will be able to use the unwinding routine from libgcc
when LIBCXXABI_USE_LLVM_UNWINDER is disabled.
llvm-svn: 226819
This commit partially reverts r219629.
This functions are not a part of ARM EHABI specification, and AFAIK,
the de facto implementation does not export these functions.
Without this change, any programs compiled with this unwind.h
will be incompatible with other implementations due to linkage
error.
llvm-svn: 226818
The NDK doesn't have access to `android/set_abort_message.h`, so use
an extern declaration instead for API 21. For older releases, just use
`__assert2`, which will report to logcat and/or the tombstone for some
older releases.
llvm-svn: 226310
libdir suffixes like 'lib64' or 'lib32'.
This support is currently very rhudimentary. We define a variable
LIBCXXABI_LIBDIR_SUFFIX. In a standalone build of libc++abi this can be
directly set as a cached variable to control the multilib suffix used.
When building libc++abi within a larger LLVM build, it is hard wired to
whatever LLVM libdir suffix has been selected. If this doesn't work for
someone, just let me know. I'm happy to change it.
Unfortunately, libc++abi's lit setup made this somewhat problematic to
change. It was setting variables up in a way that caused the resulting
build to not work with lit at all. To fix that, I've moved some
variables around in the CMake build to more closely match where and how
they are defined in the libc++ CMake build. This includes specifically
defining a library root variable in the CMake build where the libdir
suffix can be applied, and then using that rather than re-computing it
from the object directory in the lit config.
This is essentially new functionality for libc++abi so I don't expect it
to have any impact for folks until they start setting these variables.
However, I know libc++abi is built in a diverse set of environments so
just let me know if this causes you any problems.
llvm-svn: 224927
* Remove the embedded directive undefined behavior by moving the
the #ifdef out of the macro arguments. [-Wembedded-directive]
* Remove the local variable shadowing warning by renaming
frameInfo in UnwindLevel1-gcc-ext.c. [-Wshadow]
* Explicitly cast the function pointer to void pointer to avoid
the comparison between function pointer and void pointer.
[-Wpedantic]
llvm-svn: 224690
Don Hinton