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
Summary:
This switch only has an effect at link time. It changes the default
compiler support library to `compiler-rt`. With `-nodefaultlibs`, this
library won't get linked anyway; Clang actually warns about that.
Reviewers: mstorsjo, rnk
Subscribers: dberris, mgorny, christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D51645
llvm-svn: 341404
Summary:
This variable is never defined, so its value is always empty. Since
`libunwind` is needed to build the C++ ABI library in the first place,
it should never be linked to the C++ ABI library anyway.
Reviewers: mstorsjo, rnk
Subscribers: mgorny, christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D51644
llvm-svn: 341388
Summary:
By default, symbols aren't visible outside of the module that defines
them. To make them visible, they must be exported. The easiest way to do
that is to embed an `-export:symname` directive into the object file.
Reviewers: mstorsjo, rnk
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D51508
llvm-svn: 341232
Even though SEH for ARM is incomplete, make what code already exists
at least compile correctly.
The _LIBUNWIND_CURSOR_SIZE wasn't correct.
ARM (and AArch64) have a DISPATCHER_CONTEXT field named TargetPc
instead of TargetIp.
For the libunwind.h UNW_* constants, there is no UNW_ARM_PC, only
UNW_ARM_IP.
Don't use 'r' as loop variable when 'r' already is a Registers_arm
member.
Differential Revision: https://reviews.llvm.org/D51530
llvm-svn: 341217
Summary:
That attribute has no effect on Windows anyway--classes are hidden by
default.
Reviewers: mstorsjo, rnk
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D51509
llvm-svn: 341210
Summary:
I've tested this implementation on x86-64 to ensure that it works. All
`libc++abi` tests pass, as do all `libc++` exception-related tests. ARM
still remains to be implemented (@compnerd?).
Special thanks to KJK::Hyperion for his excellent series of articles on
how EH works on x86-64 Windows. (Seriously, check it out. It's awesome.)
I'm actually not sure if this should go in as is. I particularly don't
like that I duplicated the UnwindCursor class for this special case.
Reviewers: mstorsjo, rnk, compnerd, smeenai, javed.absar
Subscribers: mgorny, kristof.beyls, christof, chrib, cfe-commits, compnerd, llvm-commits
Differential Revision: https://reviews.llvm.org/D50564
llvm-svn: 341125
Testing commit access from a new machine, so using this as an opportunity to revert my old test access commit (r336006) that I never cleaned up.
llvm-svn: 339899
When compiling with optimizations, mips requires various helper routines(__ashldi3 and the like) contained in libgcc_s.
Conditionally include libgcc_s in the set of libraries to be linked to.
Differential Revision: https://reviews.llvm.org/D50243
llvm-svn: 339878
Mipsr6 does not possess HI and LO accumulator registers, adjust validRegister functions to respect that.
Differential Revision: https://reviews.llvm.org/D50244
llvm-svn: 339849
The __mips_fpr macro can take the value of 0 as well, change to account for that case.
Differential Revision: https://reviews.llvm.org/D50245
llvm-svn: 339848
This is essential when building with -nodefaultlibs.
In some CMake versions (noticed in 3.5.1), the same libraries are
picked up from CMAKE_REQUIRED_LIBRARIES in some exceptional situations
(if CXX probing failed, due to libc++ not being built yet, the libraries
from CMAKE_REQUIRED_LIBRARIES are used for linking the target library),
but not at all in other newer CMake versions (3.10).
This is similar to what already is done in libcxxabi in SVN r302760
and libcxx in SVN r312498.
Differential Revision: https://reviews.llvm.org/D50663
llvm-svn: 339642
Summary:
Make the `_Unwind_Exception` struct correct under SEH. Add a
declaration of `_GCC_specific_handler()`, which is used by SEH versions
of Itanium personality handlers to do common setup. Roughly corresponds
to Clang's D50380.
Reviewers: mstorsjo, rnk, compnerd, smeenai
Subscribers: christof, chrib, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D50414
llvm-svn: 339258
Summary:
`long` is too short on LLP64. We have to use `intptr_t` to
avoid truncating pointers.
Reviewers: mstorsjo, rnk, compnerd, smeenai
Subscribers: christof, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D50412
llvm-svn: 339217
This should resolve the breakage introduced in r337867 which introduced
the use of cmake_dependent_option without include the necessary file.
llvm-svn: 337868
Currently it's only possible to control whether shared or static library
build of libc++, libc++abi and libunwind is enabled or disabled and
whether to install everything we've built or not. However, it'd be
useful to have more fine grained control, e.g. when static libraries are
merged together into libc++.a we don't need to install libc++abi.a and
libunwind.a. This change adds this option.
Differential Revision: https://reviews.llvm.org/D49573
llvm-svn: 337867
years. Adopt the new convention that it is call-site specific and that
it should be applied before moving the IP by personality routines, but
not during normal unwinding.
Differential Revision: https://reviews.llvm.org/D38680
llvm-svn: 337312
Do not use LLVM_RUNTIMES_LIBDIR_SUFFIX variable which is an internal
variable used by the runtimes build from individual runtimes, instead
set per-runtime librarhy directory suffix variable which is necessary
for the sanitized runtimes build to install libraries into correct
location.
Differential Revision: https://reviews.llvm.org/D49121
llvm-svn: 336713
This change adds a support for multiarch style runtimes layout, so in
addition to the existing layout where runtimes get installed to:
lib/clang/$version/lib/$os
Clang now allows runtimes to be installed to:
lib/clang/$version/$target/lib
This also includes libc++, libc++abi and libunwind; today those are
assumed to be in Clang library directory built for host, with the
new layout it is possible to install libc++, libc++abi and libunwind
into the runtime directory built for different targets.
The use of new layout is enabled by setting the
LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both
projects and runtimes layouts. The runtimes CMake build has been further
modified to use the new layout when building runtimes for multiple
targets.
Differential Revision: https://reviews.llvm.org/D45604
llvm-svn: 335809
The paths output from llvm-config --cmakedir and from clang
--print-libgcc-file-name can contain backslashes, while CMake
can't handle the paths in this form.
This matches what compiler-rt already does (since SVN r203789
and r293195).
Differential Revision: https://reviews.llvm.org/D48353
llvm-svn: 335169
This makes it possible to unwind hardware exception stack frames,
which necessarily save every register and so need an extra column
for storing the return address. CFI for the exception handler could
then look as follows:
.globl exception_vector
exception_vector:
.cfi_startproc
.cfi_signal_frame
.cfi_return_column 32
l.addi r1, r1, -0x100
.cfi_def_cfa_offset 0x100
l.sw 0x00(r1), r2
.cfi_offset 2, 0x00-0x100
l.sw 0x04(r1), r3
.cfi_offset 3, 0x04-0x100
l.sw 0x08(r1), r4
.cfi_offset 4, 0x08-0x100
l.mfspr r3, r0, SPR_EPCR_BASE
l.sw 0x78(r1), r3
.cfi_offset 32, 0x78-0x100
l.jal exception_handler
l.nop
l.lwz r2, 0x00(r1)
l.lwz r3, 0x04(r1)
l.lwz r4, 0x08(r1)
l.jr r9
l.nop
.cfi_endproc
This register could, of course, also be accessed by the trace
callback or personality function, if so desired.
llvm-svn: 332513
Before this commit, R9, the link register, was used as PC register.
However, a stack frame may have R9 not set to PC on entry, either
because it uses a custom calling convention, or, more likely,
because this is a signal or exception stack frame. Using R9 as
PC register made it impossible to unwind such frames.
All other architectures similarly use a dedicated PC register.
llvm-svn: 332512
Summary:
For MIPS ABIs with 64-bit floating point registers including newabi
and O32 with 64-bit floating point registers, just save and restore the
32 floating-point registers as doubles.
For O32 MIPS with 32-bit floating-point registers, save and restore the
individual floating-point registers as "plain" registers. These registers
are encoded as floats rather than doubles, but the DWARF unwinder
assumes that floating-point registers are stored as doubles when reading
them from memory (via AddressSpace::getDouble()). Treating the
registers as "normal" registers instead causes the DWARF unwinder to
fetch them from memory as a 32-bit register. This does mean that for
O32 with 32-bit floating-point registers unw_get_fpreg() and
unw_set_fpreg() do not work. One would have to use unw_get_reg()
and unw_set_reg() instead. However, DWARF unwinding works
correctly as the DWARF CFI emits records for individual 32-bit
floating-point registers even when they are treated as doubles stored
in paired registers. If the lack of unw_get/set_fpreg() becomes a pressing
need in the future for O32 MIPS we could add in special handling to
make it work.
Reviewers: sdardis, compnerd
Reviewed By: sdardis
Differential Revision: https://reviews.llvm.org/D41968
llvm-svn: 332414
CMAKE_CXX_FLAGS and CMAKE_C_FLAGS are added twice to the command line.
This causes the command line options to be doubled which works until
it doesn't as not all options can be specified twice.
For example,
clang-cl foo.c /GS- /GS- -mllvm -small-loop-cost=1 -mllvm -small-loop-cost=1
clang (LLVM option parsing): for the -small-loop-cost option: may only occur zero or one times!
llvm-svn: 329340
Summary:
N32 uses the same register context as N64. However, N32 requires one
change to properly fetch addresses from registers stored in memory.
Since N32 is an ILP32 platform, getP() only fetches the first 32-bits
of a stored register. For a big-endian platform this fetches the
upper 32-bits which will be zero. To fix this, add a new
getRegister() method to AddressSpace which is responsible for
extracting the address stored in a register in memory. This matches
getP() for all current ABIs except for N32 where it reads the 64-bit
register and returns the low 32-bits as an address. The
DwarfInstructions::getSavedRegister() method uses
AddressSpace::getRegister() instead of AddressSpace::getP().
Reviewers: sdardis, compnerd
Reviewed By: sdardis
Differential Revision: https://reviews.llvm.org/D39074
llvm-svn: 326250
Summary:
This is done via new LIBUNWIND_TEST_COMPILER_FLAGS and
LIBUNWIND_TEST_LINKER_FLAGS variables.
Reviewed By: sdardis
Differential Revision: https://reviews.llvm.org/D43585
llvm-svn: 326223
Otherwise, a shared library build with SJLJ APIs enabled would
end up with duplicate symbols.
This didn't occur for the apple && arm case due to specifically
checking for that in the surrounding ifdef.
Differential Revision: https://reviews.llvm.org/D42555
llvm-svn: 323499
Clang and llvm already use llvm_setup_rpath(), so this change will
help standarize rpath usage across all projects.
Differential Revision: https://reviews.llvm.org/D42461
llvm-svn: 323496
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, this find_path() invocation is looking for a path in the
libcxx project 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/D41621
llvm-svn: 323141
The Registers_ppc64 class needed a couple of changes, both to accommodate the
new registers as well as to handle the overlaps of VS register set
without wasting space.
The save/restore code of V and VS registers was added.
As VS registers depend on the VMX extension, they are processed only if
VMX support is detected (_ARCH_PWR8 for now).
Patch by Leandro Lupori!
Differential Revision: https://reviews.llvm.org/D41906
llvm-svn: 322596
This is in preparation for adding support for N32 unwinding which reuses
the newabi register class.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D41842
llvm-svn: 322093
Initial working version of libunwind for PowerPC 64. Tested on
little-endian ppc64 host only.
Based on the existing PowerPC 32 code.
It supports:
- context save/restore (unw_getcontext, unw_init_local, unw_resume)
- read/write from/to saved registers
- backtrace (unw_step)
Patch by Leandro Lupori!
Differential Revision: https://reviews.llvm.org/D41386
Now builds with LIBUNWIND_ENABLE_CROSS_UNWINDING=ON should
work.
llvm-svn: 321680
For builds that only target one architecture, this was required to
be an exact match, while it previously required the allocation to be
strictly larger than the largest concrete one. Requiring it to be
larger than on equal should be enough.
This makes it more straightforward to update _LIBUNWIND_CONTEXT_SIZE
and _LIBUNWIND_CURSOR_SIZE.
llvm-svn: 321679
Initial working version of libunwind for PowerPC 64. Tested on
little-endian ppc64 host only.
Based on the existing PowerPC 32 code.
It supports:
- context save/restore (unw_getcontext, unw_init_local, unw_resume)
- read/write from/to saved registers
- backtrace (unw_step)
Patch by Leandro Lupori!
Differential Revision: https://reviews.llvm.org/D41386
llvm-svn: 321667
Instead, cast them to `void *` which has a portable format string syntax
of `%p`.
This fixes a -Wformat error when building libunwind.
llvm-svn: 321469
Right now, ARM EHABI unwind on bare metal expects to find the symbols
__exidx_start and __exidx_end defined, and uses those to locate
the EH tables. However, DWARF unwind on bare metal expects to find
dl_iterate_phdr, which, although possible to provide, is inconvenient
and mildly absurd.
This commit provides feature parity with ARM EHABI unwind by looking
for symbols __eh_frame_start, __eh_frame_end, __eh_frame_hdr_start
and __eh_frame_hdr_end, denoting the start and end of the sections
with corresponding names. As far as I know, there is no de jure or
de facto ABI providing any such names, so I chose the obvious ones.
The .eh_frame_hdr support is optional for maximum flexibility and
possible space savings (e.g. if libunwind is only used to provide
backtraces when a device crashes, providing the .eh_frame_hdr, which
is an index for rapid access to EH tables, would be a waste.)
The support for .eh_frame_hdr/DWARF index in the first place is
conditional on defined(_LIBUNWIND_SUPPORT_DWARF_INDEX), although
right now config.h will always define this macro.
The support for DWARF unwind on bare metal has been validated within
the ARTIQ environment[1].
[1]: https://m-labs.hk/artiq/
llvm-svn: 321445
Use the `_LIBUNWIND_LOG` and `_LIBUNWIND_LOG0` macros instead of
the explicit `fprintf` call.
This was previously done in r292721 as a cleanup and then reverted
in r293257 because the implementation in r292721 relied on a GNU
extension. This implementation avoids the use of an extension
by using a second macro instead, and allows to avoid the dependency
on fprintf if _LIBUNWIND_BARE_METAL is defined.
llvm-svn: 321441
This supports the soft-float ABI only and has been tested with both clang
and gcc on FreeBSD.
Reviewed By: sdardis, compnerd
Differential Revision: https://reviews.llvm.org/D38110
llvm-svn: 320528
This supports using a newer libunwind with an older installation of LLVM
(whose cmake modules wouldn't have add_llvm_install_targets).
llvm-svn: 320163
This follows the setup used by other runtimes and is expected by
the lit configuration.
Differential Revision: https://reviews.llvm.org/D40820
llvm-svn: 319830
This gains us the install-unwind-stripped target, to perform stripping
during installation.
Differential Revision: https://reviews.llvm.org/D40685
llvm-svn: 319498
This is useful in cases where we only build static library and
libunwind.a is combined with libc++abi.a into a single archive in which
case we don't want to have libunwind.a installed separately. The same
option is already provided by libcxx CMake build.
This change also adds the install-unwind target for consistency with the
libcxxabi and libcxx CMake build.
Differential Revision: https://reviews.llvm.org/D40195
llvm-svn: 318569
If the linker chose to store the full section name instead of truncating
it, this field doesn't contain a truncated name, but an offset into
the string table of the binary. The string table isn't loaded/mapped
into memory during runtime though, so it's not possible to read the
full section name, unless we try to locate the DLL/EXE on disk that
the HMODULE corresponds to and load that manually.
Due to this, lld now always prefers writing a truncated section name
for sections that will be mapped at runtime, even when debug info is
enabled.
Differential Revision: https://reviews.llvm.org/D39918
llvm-svn: 318446
This didn't require any further changes to libunwind as long as win64
in general is handled correctly.
Differential Revision: https://reviews.llvm.org/D39632
llvm-svn: 318383
James Y Knight