I believe this is an oversight from the import of libunwind into its own
library from libc++abi.
In libc++abi, these files had the .s suffix, which indicates that the file
is a preprocessed assembly source file. This caused problems because the
files rely upon preprocessors to guard target-specific blocks.
To fix this, the CMakeLists file marked these files as C so that the
preprocessor would be run over them, but then the compiler would correctly
identify the files as assembly and compile them as such.
When imported to libunwind, these files were (correctly) renamed with .S
suffixes, which are non-preprocessed assembly. Thus, we no longer need the
C language property.
The benefit here is that the files can now benefit from CMAKE_ASM_FLAGS
rather than CMAKE_C_FLAGS.
Patch By: JamesNagurne
Differential Revision: https://reviews.llvm.org/D72952
reg is unsigned type and used here for getting array element from the end by
negating it. negation of unsigned can result in large number and array access
with that index will result in segmentation fault.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=43872
Patched by: kamlesh kumar
Differential Revision: https://reviews.llvm.org/D69893
Summary:
Add unwinding support for 64-bit RISC-V.
This is from the FreeBSD implementation with the following minor
changes:
- Renamed and renumbered DWARF registers to match the RISC-V ABI [1]
- Use the ABI mneumonics in getRegisterName() instead of the exact
register names
- Include checks for __riscv_xlen == 64 to facilitate adding the 32-bit
ABI in the future.
[1] https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md
Patch by Mitchell Horne (mhorne)
Reviewers: lenary, luismarques, compnerd, phosek
Reviewed By: lenary, luismarques
Subscribers: arichardson, sameer.abuasal, abidh, asb, aprantl, krytarowski, simoncook, kito-cheng, christof, shiva0217, rogfer01, rkruppe, PkmX, psnobl, benna, lenary, s.egerton, luismarques, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D68362
Summary:
Relands https://reviews.llvm.org/D70815.
The original commit set `CMAKE_TRY_COMPILE_TARGET_TYPE` to
`STATIC_LIBRARY` globally in libunwind/CMakeLists.txt, which effectively
disabled the linking step in CMake checks.
This broke some builds (see 938c70b86c).
Here we set CMAKE_TRY_COMPILE_TARGET_TYPE to
STATIC_LIBRARY only when checking for presence of the `-funwind-tables`
flag, and then set it back to the original value so it doesn't affect
other checks.
Reviewers: mstorsjo, jfb
Subscribers: mgorny, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D71117
This reverts commit b3fdf33ba6.
This change broke building libunwind for Windows/MinGW, and broke
on aspect of the CMake tests in libunwind in general.
After set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY), CMake
skips the linking step in tests, but cmake/config-ix.cmake also
does a few checks for functions in libraries (looking for whether
-lc provides fopen and whether -ldl provides dladdr).
As CMake only tests building a static library, these tests
incorrectly succeed and CMake concludes "Looking for fopen in c -
found" and "Looking for dladdr in dl - found", while building
then fails at the end with errors about unable to find -lc and -ldl.
Summary:
Or, rather, don't accidentally forget to pass it.
This is aimed to solve the problem discussed in [this thread](http://lists.llvm.org/pipermail/llvm-dev/2019-November/136890.html), and to fix [a year-old bug](https://bugs.llvm.org/show_bug.cgi?id=38468).
TL;DR: when building libunwind for ARM Linux, we **need** libunwind to be built with the `-funwind-tables` flag, because, well ARM EHABI needs unwind info produced by this flag. Without the flag all the procedures in libunwind are marked `.cantunwind`, which causes all sorts of bad things. From `_Unwind_Backtrace` not working, to C++ exceptions not being caught (which is the aforementioned bug is about).
Previously, this flag was not added because the CMake check `add_compile_flags_if_supported(-funwind-tables)` produced a false negative. Why? With this flag, the compiler generates calls to the `__aeabi_unwind_cpp_pr0` symbol, which is defined in libunwind itself and obviously is not available at configure time, before libunwind is built. This led to failure at link time during the CMake check. We handle this by disabling the linker for CMake checks in linbunwind.
Also, this patch introduces a lit feature `libunwind-arm-ehabi`, which is used to mark the `signal_frame.pass.cpp` test as unsupported (as was advised by @miyuki in D70397).
Reviewers: peter.smith, phosek, EricWF, compnerd, jroelofs, saugustine, miyuki, jfb
Subscribers: mgorny, kristof.beyls, christof, libcxx-commits, miyuki
Tags: #libc
Differential Revision: https://reviews.llvm.org/D70815
996e62eef7 added Linux-specific dependent libraries to libunwind
sources. As a result, building libunwind with modern LLD on *BSD
started failing due to trying to link libdl. Instead, add those
libraries only if they were detected by CMake.
While technically we could create a long list of systems that need -ldl
and -lpthread, maintaining a duplicate list makes little sense when
CMake needs to detect it for non-LLD systems anyway. Remove existing
system exceptions since they should be covered by the CMake check
anyway.
Remove -D_LIBUNWIND_HAS_COMMENT_LIB_PRAGMA since it is no longer
explicitly needed, if we make the library-specific defines dependent
on presence of this pragma support.
Differential Revision: https://reviews.llvm.org/D70868
Summary:
This patch adjusts the signal_frame.pass.cpp to pass on Arm targets:
* When Arm EHABI is used the unwinder does not use DWARF, hence the
DWARF-specific check unw_is_signal_frame() must be disabled.
* Certain C libraries don't include EH tables, so the unwinder must
not try to step out of main(). The patch moves the test code out of
main() into a separate function to avoid this.
Reviewers: saugustine, ostannard, phosek, jfb, mclow.lists
Reviewed By: saugustine
Subscribers: dexonsmith, aprantl, kristof.beyls, christof, libcxx-commits, pbarrio, labrinea
Tags: #libc
Differential Revision: https://reviews.llvm.org/D70397
A "signal frame" is a function or block of code where execution arrives via a signal or interrupt, rather than via a normal call instruction. In fact, a particular instruction is interrupted by the signal and needs to be restarted. Therefore, when the signal handler is complete, execution needs to return to the interrupted instruction, rather than the instruction immediately following the call instruction, as in a normal call.
Stack unwinders need to know this to correctly unwind signal frames. Dwarf handily provides an "S" in the CIE augmentation string to describe this case, and the libunwind API provides various functions to for unwinders to determine it,.
The llvm libunwind implementation correctly sets it's internal variable "isSignalFrame" when initializing an unwind context. However, upon stepping up the stack, the current implementation correctly reads the augmentation string and sets it in the CIE info (which it then discards), libunwind doesn't update it's internal unwind context data structure.
This change fixes that, and provides compatibility with both the canonical libunwind and the libgcc implementation.
Reviewers: jfb
Subscribers: christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D69677
Have CMake treat the unwind libraries as C libraries rather than C++.
There is no C++ runtime dependency at runtime. This ensures that we do
not accidentally end up with a link against the C++ runtime.
We need to explicitly reset the implicitly linked libraries for C++ to
ensure that we do not have CMake force the link against the C++ runtime.
This adjustment should enable the NetBSD bots to be happy with this
change.
Disable the type information emission for libunwind. libunwind does not
use `dynamic_cast`. This results in a smaller binary, and more
importantly, avoids the dependency on libc++abi. This ensures that we
have complete symbol resolution of symbols on ELF targets without
linking to the C++ runtime support library. This change avoids the
emission of a reference to `__si_class_type_info`.
The unwinder should not depend on libc++. In fact, we do not end up
with a link against libc++ as we do not have a dependency on libc++ at
runtime. This ensures that we link with `clang` rather than `clang++`.
Summary:
Fix the arm_section_length count. The meaning of the arm_section_length
field changed from num-of-elements to num-of-bytes when the
dl_unwind_find_exidx special case was removed (D30306 and D30681). The
special case was restored in D39468, but that patch didn't account for the
change in arm_section_length's meaning.
That patch worked when it was applied to the NDK's fork of libunwind,
because it never removed the special case in the first place, and the
special case is probably disabled in the Android platform's copy of
libunwind, because __ANDROID_API__ is greater than 21.
Turn the dl_unwind_find_exidx special case on unconditionally for Bionic.
Bionic's dl_unwind_find_exidx is much faster than using dl_iterate_phdr.
(e.g. Bionic stores exidx info on an internal soinfo object.)
Reviewers: thomasanderson, srhines, danalbert, ed, keith.walker.arm, mclow.lists, compnerd
Reviewed By: srhines, danalbert
Subscribers: srhines, kristof.beyls, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68972
llvm-svn: 375275
Summary:
The workaround added in https://reviews.llvm.org/rL299575 appears to be
working around a bug in Android JB 4.1.x and 4.2.x (API 16 and 17).
Starting in API 16, Android added support for PIE binaries, but the
dynamic linker failed to initialize dlpi_addr to the address that the
executable was loaded at. The bug was fixed in Android JB 4.3.x (API 18).
Improve the true load bias calculation:
* The code was assuming that the first segment would be the PT_PHDR
segment. I think it's better to be explicit and search for PT_PHDR. (It
will be almost as fast in practice.)
* It's more correct to use p_vaddr rather than p_offset. If a PIE
executable is linked with a non-zero image base (e.g. lld's
-Wl,--image-base=xxxx), then we must use p_vaddr here.
The "phdr->p_vaddr < image_base" condition seems unnecessary and maybe
slightly wrong. If the OS were to load a binary at an address smaller than
a vaddr in the binary, we would still want to do this workaround.
The workaround is safe when the linker bug isn't present, because it
should calculate an image_base equal to dlpi_addr. Note that with API 21
and up, this workaround should never activate for dynamically-linked
objects, because non-PIE executables aren't allowed.
Consolidate the fix into a single block of code that calculates the true
image base, and make it clear that the fix no longer applies after API 18.
See https://github.com/android/ndk/issues/505 for details.
Reviewers: mclow.lists, srhines, danalbert, compnerd
Reviewed By: compnerd
Subscribers: srhines, krytarowski, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68971
llvm-svn: 374969
There are few differences in compile flags introduced in r374606
which are causing libcxx-libcxxabi-libunwind-armv8-linux to fail.
This change should address all of those, I've compared the generated
build file from before r374606 and with this change and the set of
flags is the same modulo order.
llvm-svn: 374624
libunwind was using its own set of macros/functions for flag checking
which was similar but different from libc++ and libc++abi. This made
it difficult to replicate the same checks across projects, in fact
there were some checks that appear to have been copy & pasted from
another project and that were broken in the standalone libunwind build.
This change refactors flag checks to match libc++ and libc++abi using
a copy of HandleLibunwindFlags.cmake which is derived from the versions
used by the other projects. This also paves a road to deduplicating and
unifying HandleLibunwindFlags.cmake, HandleLibcxxabiFlags.cmake and
HandleLibcxxFlags.cmake post monorepo switch.
Differential Revision: https://reviews.llvm.org/D68855
llvm-svn: 374606
ARM EHABI unwinding tables only store the start address of each function, so the
last function is assumed to cover the entire address space after it. The test
picks an address on the stack assuming that it's in no function, but because of
the above it's actually resolved to the last function. Fix this by using address
0 instead.
Differential Revision: https://reviews.llvm.org/D68387
llvm-svn: 373628
Move the definition of Elf_Addr typedef to the only place it is used, to avoid:
```
llvm-project/libunwind/src/AddressSpace.hpp:501:28: warning: unused typedef 'Elf_Addr' [-Wunused-local-typedef]
```
when compiling for Android with _LIBUNWIND_ARM_EHABI defined and
_LIBUNWIND_SUPPORT_DWARF_UNWIND not defined.
Patch by Joel Klinghed!
llvm-svn: 372427
If unwind info is not available at the current IP, unw_get_proc_info should
return a zero-filled structure rather than the info of the previous IP.
This change also makes unw_get_proc_info return UNW_ENOINFO instead of
UNW_ESUCCESS.
Patch by Amanieu d'Antras!
llvm-svn: 372407
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 is a small fix for https://reviews.llvm.org/D64996. The types of
w0 and w1 in _Unwind_VRS_Get must be uint64_t, not uint32_t.
Committing as obvious.
llvm-svn: 366701
Summary:
The function Unwind-EHABI.cpp:_Unwind_VRS_Pop loads the saved values of
64-bit FP registers as two 32-bit words because they might not be
8-byte aligned. Combining these words into a 64-bit value has to be
done differently on big-endian platforms.
Reviewers: ostannard, john.brawn, dmgreen
Reviewed By: ostannard
Subscribers: kristof.beyls, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D64996
llvm-svn: 366587
Summary:
The function getByte is dependent on endianness and the current
behavior is incorrect on big-endian targets.
This patch fixes the issue.
Reviewers: phosek, ostannard, dmgreen, christof, chill
Reviewed By: ostannard, chill
Subscribers: chill, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D64402
llvm-svn: 365505
Summary:
The AArch64 version of the libunwind function which restores the
CPU state and resumes execution is not interrupt-safe. It restores
the target value of SP before loading the floating-point registers
from the context struct, but that struct is allocated on the stack
which is being deallocated. This means that if an interrupt occurs
during this function, and uses a lot of stack space, it could
overwrite the values about to be loaded into the floating-point
registers.
This patch fixes the issue.
Patch by Oliver Stannard.
Reviewers: phosek, chill
Reviewed By: chill
Subscribers: chill, javed.absar, kristof.beyls, christof, LukeCheeseman, pbarrio, olista01, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D63006
llvm-svn: 363545
Summary:
This updates all places in documentation that refer to "Mac OS X", "OS X", etc.
to instead use the modern name "macOS" when no specific version number is
mentioned.
If a specific version is mentioned, this attempts to use the OS name at the time
of that version:
* Mac OS X for 10.0 - 10.7
* OS X for 10.8 - 10.11
* macOS for 10.12 - present
Reviewers: JDevlieghere
Subscribers: mgorny, christof, arphaman, cfe-commits, lldb-commits, libcxx-commits, llvm-commits
Tags: #clang, #lldb, #libc, #llvm
Differential Revision: https://reviews.llvm.org/D62654
llvm-svn: 362113
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
Fix two issues that caused libcxx source path not to be inferred
correctly when not specified explicitly:
1. get_lit_conf() uses default value only if the lit variable is set
to None. Due to the mehod of substituting lit.site.cfg, they were
"" rather than None when unset, effectively causing the default never
to apply. Instead, use 'or' construct to use the default whenever
get_lit_conf() returns a false value.
2. If os.path.join() is given a component starting with '/', it takes
it to be an absolute path and ignores everything preceding it.
Remove the slash to correctly append subdirectory.
With these two fixes, libunwind tests start working on NetBSD buildbot
again.
Differential Revision: https://reviews.llvm.org/D62005
llvm-svn: 361931
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
Clang integrated assembler was unable to build libunwind PPC32 assembly code,
present in functions used to save/restore register context.
This change consists in replacing the assembly style used in libunwind source,
to one that is compatible with both Clang integrated assembler as well as
GNU assembler.
Patch by Leandro Lupori!
Differential Revision: https://reviews.llvm.org/D61792
llvm-svn: 360862
This change makes each unwind step inspect the instruction at the
return address and, if needed, read r2 from its saved location and
modify the context appropriately.
The unwind logic is able to handle both ELFv1 and ELFv2 stacks.
Reported by Bug 41050
Patch by Leandro Lupori!
Differential Revision: https://reviews.llvm.org/D59694
llvm-svn: 360861
calls into the pthread library use weak symbols.
This option allows libpthread to be a weak dependency rather
than a hard one.
Differential Revision: https://reviews.llvm.org/D60285
llvm-svn: 360610
This change introduces support for building libuwind. 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/D60370
llvm-svn: 359804
For builds with SJLJ, there is no __unw_getcontext symbol. On Windows,
the weak alias macro also expands to a dllexport directive, which fails
if the symbol doesn't exist.
Differential Revision: https://reviews.llvm.org/D60251
llvm-svn: 357711
This is not necessary for ELF since .globl and .weak are mutually
exclusive, but is necessary for Mach-O otherwise the symbol isn't
visible externally.
Differential Revision: https://reviews.llvm.org/D60245
llvm-svn: 357671
libunwind defines the _Unwind_* ABI used by libc++abi. This ABI is a
stable quasi-standard common between multiple implementations such as
LLVM and GNU. The _U* symbol name space is also safely within the symbol
name space that standard C & C++ reserve for the implementation.
Futhermore, libunwind also defines several unw_* symbols, and references
these from the _Unwind_* entry points so the standard/reserved part of
the ABI is dependent on the unw_* part of the ABI. This is not OK for a
C or C++ implementation. The unw_* symbols are reserved for C and extern
"C" used by application code.
This change renames each unw_* function to __unw* and adds a weak alias
unw_* to keep the public <libunwind.h> ABI unchanged for backwards
compatibility. Every reference to unw_* in the implementation has been
changed to use __unw* so that if other unw_* definitions are in force
because nothing uses <libunwind.h> in a particular program, no _Unwind*
code path depends on any unw_* symbol. Furthemore, __unw_* symbols are
hidden, which saves PLT overhead in the shared library case.
In the future, we should cconsider untangling the unw_* API/ABI from the
_Unwind_* API/ABI. The internal API backing the _Unwind_* ABI
implementation should not rely on any nonstandard symbols not in the
implementation-reserved name space. This would then allow separating the
_Unwind_* API/ABI from unw_* entirely, but that's a more substantial
change that's going to require more significant refactoring.
Differential Revision: https://reviews.llvm.org/D59921
llvm-svn: 357640
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
If we're not in a standalone build, this variable should be already
set, so there's no need to set it again or to cache it.
Differential Revision: https://reviews.llvm.org/D57993
llvm-svn: 353915
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
While Clang automatically generates the code for placement new,
g++ doesn't do that so we need to provide our own definition.
Differential Revision: https://reviews.llvm.org/D57455
llvm-svn: 352966
This is unfinished, unused and incomplete. This could be brought back in
the future if there's a desire to build a more complete implementation,
but at the moment it's just bitrotting.
Differential Revision: https://reviews.llvm.org/D57252
llvm-svn: 352965
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
We haven't eliminated C++ library dependency altogether in D57251,
UnwindCursor.hpp had an unused dependency on <algorithm> which was
pulling in other C++ headers. Removing that dependency also revealed
(correctly) that we need our own global placement new declaration. Now
libunwind should be independent of the C++ library.
Differential Revision: https://reviews.llvm.org/D57262
llvm-svn: 352553
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
The existing typedef of unw_fpreg_t to uint64_t might work and be
correct for the ARM_EHABI case, but for dwarf, some cases in e.g.
DwarfInstructions.hpp convert between double and unw_fpreg_t.
When converting implicitly between double and unw_fpreg_t (uint64_t),
the values get interpreted as integers and converted to float and vice
versa, while the correct thing would be to keep the same bit pattern.
Avoid the whole issue by using the same definition of unw_fpreg_t
as all other architectures, when using dwarf unwinding on ARM.
Change assembler functions to take a void pointer instead of
unw_fpreg_t pointer, to avoid having a different mangled symbol name
depending on the actual value of this typedef.
Differential Revision: https://reviews.llvm.org/D57001
llvm-svn: 352461
We haven't eliminated C++ library dependency altogether in D57251,
UnwindCursor.hpp had an unused dependency on <algorithm> which was
pulling in other C++ headers. Removing that dependency also revealed
(correctly) that we need our own global placement new declaration. Now
libunwind should be independent of the C++ library.
Differential Revision: https://reviews.llvm.org/D57262
llvm-svn: 352384
The check_library_exists CMake uses a custom symbol definition. This
is a problem when checking for C library symbols because Clang
recognizes many of them as builtins, and returns the
-Wbuiltin-requires-header (or -Wincompatible-library-redeclaration)
error. When building with -Werror which is the default, this causes
the check_library_exists check fail making the build think that C
library isn't available.
To avoid this issue, we should use a symbol that isn't recognized by
Clang and wouldn't cause the same issue. __libc_start_main seems like
reasonable choice that fits the bill.
Differential Revision: https://reviews.llvm.org/D57142
llvm-svn: 352341
The rest of libunwind already uses placement new, these are the only
places where non-placement new is being used introducing undesirable
C++ library dependency.
Differential Revision: https://reviews.llvm.org/D57251
llvm-svn: 352245
Recent Linux kernel release has introduced a bug as part of the ORC
rollout where the vDSO has a valid .eh_frame section, but it's missing
the .eh_frame_hdr section and GNU_EH_FRAME segment has zero size. This
causes libunwind to abort which breaks programs that use libunwind.
The other unwinder implementation (libgcc, non-gnu) instead silently
bail out unless being compiled as debug. This change modifies libunwind
to use the same strategy.
Differential Revision: https://reviews.llvm.org/D57081
llvm-svn: 352016
Either adjust the format string to use a more exact type, or add casts
(for cases when printing pointers to structs/objects with a %p
format specifier).
Differential Revision: https://reviews.llvm.org/D56982
llvm-svn: 351876
When built within the llvm runtimes directory, the runtimes
CMakeLists.txt adds the same.
Differential Revision: https://reviews.llvm.org/D56981
llvm-svn: 351875
all missed!
Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.
llvm-svn: 351731
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
This installs the new developer policy and moves all of the license
files across all LLVM projects in the monorepo to the new license
structure. The remaining projects will be moved independently.
Note that I've left odd formatting and other idiosyncracies of the
legacy license structure text alone to make the diff easier to read.
Critically, note that we do not in any case *remove* the old license
notice or terms, as that remains necessary until we finish the
relicensing process.
I've updated a few license files that refer to the LLVM license to
instead simply refer generically to whatever license the LLVM project is
under, basically trying to minimize confusion.
This is really the culmination of so many people. Chris led the
community discussions, drafted the policy update and organized the
multi-year string of meeting between lawyers across the community to
figure out the strategy. Numerous lawyers at companies in the community
spent their time figuring out initial answers, and then the Foundation's
lawyer Heather Meeker has done *so* much to help refine and get us ready
here. I could keep going on, but I just want to make sure everyone
realizes what a huge community effort this has been from the begining.
Differential Revision: https://reviews.llvm.org/D56897
llvm-svn: 351631
GCC and Clang in MinGW mode don't support __declspec(thread), which
after expanding macros ends up as __attribute__((thread)). Use the
GCC specific attribute __thread instead (the next one in the chain
of alternatives).
Differential Revision: https://reviews.llvm.org/D56905
llvm-svn: 351587
Summary:
Adds the register class implementation for Sparc.
Adds support for DW_CFA_GNU_window_save.
Adds save and restore context functionality.
Adds getArch() function to each Registers_ class to be able to separate
between DW_CFA_AARCH64_negate_ra_state and DW_CFA_GNU_window_save which
are both represented by the same constant.
On Sparc the return address is the address of the call instruction, so
an offset needs to be added when returning to skip the call instruction
and its delay slot. If the function returns a struct it is also necessary
to skip one extra instruction on Sparc V8.
Reviewers: jyknight, mclow.lists, mstorsjo, compnerd
Reviewed By: jyknight, compnerd
Subscribers: jgorbe, mgorny, christof, llvm-commits, fedor.sergeev, JDevlieghere, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D55763
llvm-svn: 351044
Summary:
Adds the register class implementation for Sparc.
Adds support for DW_CFA_GNU_window_save.
Adds save and restore context functionality.
On Sparc the return address is the address of the call instruction,
so an offset needs to be added when returning to skip the call instruction
and its delay slot. If the function returns a struct it is also necessary
to skip one extra instruction.
Reviewers: jyknight, mclow.lists, mstorsjo, compnerd
Reviewed By: compnerd
Subscribers: fedor.sergeev, JDevlieghere, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D55763
llvm-svn: 350705
This doesn't yet implement inspecting the .pdata/.xdata to find the
LSDA pointer (in UnwindCursor::getInfoFromSEH), but normal C++
exception handling seems to run just fine without it. (The only
place I can see where it's even referenced is in
unwind_phase2_forced, and I can't find a codepath where libcxxabi
would end up calling that.)
Differential Revision: https://reviews.llvm.org/D55674
llvm-svn: 349532
- Support for the case where the return address has been signed with the B key
- When the B key is used, a 'B' character is present in the augmentation string
of CIE associated with the FDE for the function.
Differential Revision: https://reviews.llvm.org/D55704
llvm-svn: 349339
- Follow up to revision r342895
- gcc would not build libunwind with the earlier patch as the autia1716
instruction wasn't allowed to be assembled for pre armv8.3a targets
- The autia1716 instruction lives in the hint space encodings so is a valid
instruction for all armv8a targets
- To work around this I have swapped out the autia1716 instruction for the hint
instruction
Differential Revision: https://reviews.llvm.org/D55700
llvm-svn: 349140
Rename the 'append_if' macro used in libunwind to 'unwind_append_if'.
Otherwise, when used in a combined LLVM+libunwind build, it overrides
the *incompatible* 'append_if' function from LLVM and breaks projects
following libunwind, e.g. OpenMP.
Differential Revision: https://reviews.llvm.org/D55476
llvm-svn: 348852
This is needed when cross-compiling for a different target since
CFLAGS may contain additional flags like -resource-dir which
change the location in which compiler-rt builtins are found.
Differential Revision: https://reviews.llvm.org/D54371
llvm-svn: 346820
Summary:
If `-nodefaultlibs` is given, we weren't actually linking to it. This
was true irrespective of passing `-rtlib=compiler-rt` (see previous
patch). Now we explicitly link it to handle that case.
I wonder if we should be linking these libraries only if we're using
`-nodefaultlibs`...
Reviewers: beanz
Subscribers: dberris, mgorny, christof, chrib, cfe-commits
Differential Revision: https://reviews.llvm.org/D51657
llvm-svn: 343990
- When return address signing is enabled, the LR may be signed on function entry
- When an exception is thrown the return address is inspected used to unwind the call stack
- Before this happens, the return address must be correctly authenticated to avoid causing an abort by dereferencing the signed pointer
Differential Revision: https://reviews.llvm.org/D51432
llvm-svn: 342895
James Nagurne