Commit Graph

485 Commits

Author SHA1 Message Date
Louis Dionne 56b74613bf [libunwind] Take 2: Use the from-scratch testing configuration by default
Summary:
This commit switches libunwind from using the complicated logic in
libc++'s testing configuration to a from-scratch configuration.
I tried to make sure that all cases that were handled in the old
config were handled by this one too, so hopefully this shouldn't
break anyone. However, if you encounter issues with this change,
please let me know and feel free to revert if I don't reply quickly.

This change was engineered to be easily revertable.

This commit is a re-application of 5a8ad80b6f, which was reverted in
070a2ddcb6 because it broke the Bootstrapping build. This has now been
addressed by tweaking the from-scratch config.

Differential Revision: https://reviews.llvm.org/D112082
2021-10-26 09:34:40 -04:00
Louis Dionne e6f39c8b48 [libunwind] Fix path to libunwind for per-target-runtime-dir builds
We recently introduced a from-scratch config to run the libunwind tests.
However, that config was always looking for libunwind in <install>/lib,
and never in <install>/<target>/lib, which is necessary for tests to
work when the per-target-runtime-dir configuration is enabled.

This commit fixes that. I believe this is what caused the CI failures we
saw after 5a8ad80b6f and caused it to be reverted.

Differential Revision: https://reviews.llvm.org/D112322
2021-10-22 14:36:14 -04:00
Petr Hosek ba4920e98e Revert "[CMake] Cache the compiler-rt library search results"
This reverts commit 0eed292fba, there
are compiler-rt build failures that appear to have been introduced
by this change.
2021-10-21 10:32:01 -07:00
Louis Dionne 72117f2ffe [runtimes] Properly handle the sysroot/triple/gcc-toolchain
In 395271a, I simplified how we handled the target triple for the
runtimes. However, in doing so, we stopped considering the default
in CMAKE_CXX_COMPILER_TARGET, so we'd use the LLVM_DEFAULT_TARGET_TRIPLE
(which is the host triple) even if CMAKE_CXX_COMPILER_TARGET was specified.
This commit fixes that problem and also refactors the code so that it's
easy to see what the default value is.

The fact that nobody seems to have been broken by this makes me think
that perhaps nobody is using CMAKE_CXX_COMPILER_TARGET to specify the
triple -- but it should still work.

Differential Revision: https://reviews.llvm.org/D111672
2021-10-21 10:06:11 -04:00
Louis Dionne 070a2ddcb6 [libunwind] Revert "Use the from-scratch testing configuration by default"
This reverts commit 5a8ad80b6f, which broke
the Bootstrapping build. I'm reverting until we've fixed the issue.

Differential Revision: https://reviews.llvm.org/D112082
2021-10-20 17:40:23 -04:00
Louis Dionne 5a8ad80b6f [libunwind] Use the from-scratch testing configuration by default
This commit switches libunwind from using the complicated logic in
libc++'s testing configuration to a from-scratch configuration.
I tried to make sure that all cases that were handled in the old
config were handled by this one too, so hopefully this shouldn't
break anyone. However, if you encounter issues with this change,
please let me know and feel free to revert if I don't reply quickly.

This change was engineered to be easily revertable.

Differential Revision: https://reviews.llvm.org/D112082
2021-10-20 08:45:58 -04:00
Louis Dionne 6fd55bba61 [libunwind] Add a from-scratch config for running libunwind tests
Running tests for libunwind is a lot simpler than running tests for
libc++, so a simple Lit config file is sufficient. The benefit is that
we disentangle the libunwind test configuration from the libc++ and
libc++abi test configuration. The setup was too complicated, which led
to some bugs (notably we were running against the system libunwind on
Apple platforms).

Differential Revision: https://reviews.llvm.org/D111664
2021-10-19 12:03:58 -04:00
Petr Hosek 0eed292fba [CMake] Cache the compiler-rt library search results
There's a lot of duplicated calls to find various compiler-rt libraries
from build of runtime libraries like libunwind, libc++, libc++abi and
compiler-rt. The compiler-rt helper module already implemented caching
for results avoid repeated Clang invocations.

This change moves the compiler-rt implementation into a shared location
and reuses it from other runtimes to reduce duplication and speed up
the build.

Differential Revision: https://reviews.llvm.org/D88458
2021-10-18 14:44:07 -07:00
Louis Dionne df3de7647e [libc++abi] Change LIBCXXABI_NO_TIMER to LIBCXXABI_USE_TIMER
Instead of always defining LIBCXXABI_NO_TIMER to run the tests, only
define LIBCXXABI_USE_TIMER when we want to enable the timer. This makes
the libc++abi testing configuration simpler.

As a fly-by fix, remove the unused LIBUNWIND_NO_TIMER macro from libunwind.

Differential Revision: https://reviews.llvm.org/D111667
2021-10-13 08:02:31 -04:00
Louis Dionne f6a74908a7 [runtimes] Add tests for vendor-specific properties
Vendors take libc++ and ship it in various ways. Some vendors might
ship it differently from what upstream LLVM does, i.e. the install
location might be different, some ABI properties might differ, etc.

In the past few years, I've come across several instances where
having a place to test some of these properties would have been
incredibly useful. I also just got bitten by the lack of tests
of that kind, so I'm adding some now.

The tests added by this commit for Apple platforms have numerous
TODOs that capture discrepancies between the upstream LLVM CMake
and the slightly-modified build we perform internally to produce
Apple's system libc++. In the future, the goal would be to upstream
all those differences so that it's possible to build a faithful
Apple system libc++ with the upstream LLVM sources only.

But this isn't only useful for Apple - this lays out the path for
any vendor being able to add their own checks (either upstream or
downstream) to libc++.

This is a re-application of 9892d1644f, which was reverted in 138dc27186
because it broke the build. The issue was that we didn't apply the required
changes to libunwind and our CI didn't notice it because we were not
running the libunwind tests. This has been fixed now, and we're running
the libunwind tests in CI now too.

Differential Revision: https://reviews.llvm.org/D110736
2021-10-07 15:46:20 -04:00
Louis Dionne 60fe1f59d0 [runtimes][ci] Run the tests for libunwind in the CI
We should arguably have always been doing that. The state of libunwind
is quite sad, so this commit adds several XFAILs to make the CI pass.
We need to investigate why so many tests are not passing in some
configurations, but I'll defer that to folks who actually work on
libunwind for lack of bandwidth.

Differential Revision: https://reviews.llvm.org/D110872
2021-10-06 11:25:26 -04:00
Louis Dionne 54a8a0d09a [runtimes] Allow FOO_TEST_CONFIG to be a relative path
That makes it possible to store that value in a CMake cache if needed.

Differential Revision: https://reviews.llvm.org/D110843
2021-10-05 19:45:50 -04:00
Daniel Kiss 532783f9e1 [libunwind] Fix cfi_register for float registers.
Fixes D110144.
registers.getFloatRegister is not const in ARM therefor can't be called here.

Reviewed By: mstorsjo, #libunwind

Differential Revision: https://reviews.llvm.org/D110731
2021-10-01 16:51:51 +02:00
Daniel Kiss 77aa9ca92a [libunwind] Support cfi_undefined and cfi_register for float registers.
During a backtrace the `.cfi_undefined` for a float register causes an assert in libunwind.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D110144
2021-09-27 12:04:02 +02:00
Alfonso Gregory a2c319fdc6 [LLVM][CMake][NFC] Resolve FIXME: Rename LLVM_CMAKE_PATH to LLVM_CMAKE_DIR throughout the project
This way, we do not need to set LLVM_CMAKE_PATH to LLVM_CMAKE_DIR when (NOT LLVM_CONFIG_FOUND)

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D107717
2021-09-16 18:29:57 +02:00
Martin Storsjö c4e8a2136c [runtimes] Allow overriding where CMake installs RUNTIME type libraries (DLLs)
Differential Revision: https://reviews.llvm.org/D107892
2021-09-09 00:01:38 +03:00
Hans Wennborg 1bc175d486 [Unwind] Cast exception class pointer for strcpy
Follow-up to f5b997e6b7, see comment on
https://reviews.llvm.org/D109047

Differential revision: https://reviews.llvm.org/D109168
2021-09-02 19:01:30 +02:00
Daniel Kiss d212bdf828 [libunwind] Compile with -Wunused-but-set-variable
-Wunused-but-set-variable triggers a warning even the block of code is effectively dead.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D107835
2021-09-02 11:43:20 +02:00
Daniel Kiss f5b997e6b7 [Unwind] Harmonise exception class for EHABI spec.
EHABI defines the exception class as char[8] instead of uint64_t [1].
For ABI compatibility the ABI the definition needs to be updated.

[1] https://github.com/ARM-software/abi-aa/blob/main/ehabi32/ehabi32.rst#82language-independent-unwinding-types-and-functions

Reviewed By: manojgupta, MaskRay, #libunwind

Differential Revision: https://reviews.llvm.org/D109047
2021-09-02 11:31:03 +02:00
Benjamin Kramer 5ece556271 [libunwind] Don't include cet.h/immintrin.h unconditionally
These may not exist when CET isn't available.
2021-08-26 11:37:07 +02:00
gejin 21b25a1fb3 [libunwind] Support stack unwind in CET environment
Control-flow Enforcement Technology (CET), published by Intel,
introduces shadow stack feature aiming to ensure a return from
a function is directed to where the function was called.
In a CET enabled system, each function call will push return
address into normal stack and shadow stack, when the function
returns, the address stored in shadow stack will be popped and
compared with the return address, program will fail if the 2
addresses don't match.
In exception handling, the control flow may skip some stack frames
and we must adjust shadow stack to avoid violating CET restriction.
In order to achieve this, we count the number of stack frames skipped
and adjust shadow stack by this number before jumping to landing pad.

Reviewed By: hjl.tools, compnerd, MaskRay
Differential Revision: https://reviews.llvm.org/D105968

Signed-off-by: gejin <ge.jin@intel.com>
2021-08-26 16:20:38 +08:00
Fangrui Song 9ae9dd3fcf [libunwind] Add UNW_AARCH64_* beside UNW_ARM64_*
The original libunwind project defines UNW_AARCH64_* instead of UNW_ARM64_*.
Rename the enum members to match. This allows some applications with simple
`unw_init_local` usage to migrate to llvm-project libunwind.

Note: the canonical names of `UNW_ARM_D{0..31}` are now `UNW_AARCH64_V{0..31}`,
to match the original libunwind.

UNW_ARM64_* are kept for now for compatibility. Some may be unneeded and can be
cleaned up in the future.

Reviewed By: #libunwind, compnerd

Differential Revision: https://reviews.llvm.org/D107996
2021-08-20 14:26:27 -07:00
Vitaly Buka 2f1ee56f3c [unwind] Handle UNW_X86_64_RIP register
In some binaries, built with clang/lld, libunwind crashes
with "unsupported x86_64 register" for regNum == 16:

Differential Revision: https://reviews.llvm.org/D107919
2021-08-12 12:08:07 -07:00
Daniel Kiss 6b6d344731 [libunwind] Compile with -Wunused-but-set-variable
-Wunused-but-set-variable triggers a warning even the block of code is effectively dead.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D107835
2021-08-11 10:15:54 +02:00
Daniel Kiss db126ae243 [Arm][Unwind][libc++abi] Add _Unwind_ForcedUnwind to EHABI.
_Unwind_ForcedUnwind is not mandated by the EHABI but for compatibilty
reasons adding so the interface to higher layers would be the same.
Dropping EHABI specific _Unwind_Stop_Fn definition since it is not defined by EHABI.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D89570
2021-08-11 10:15:53 +02:00
Daniel Kiss 9ed1c7e496 [Unwind] Split unwind.h
Moving Itanium and ArmEHABI specific implementations to dedicated files.
This is a NFC patch.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D106461
2021-08-11 10:15:51 +02:00
Saleem Abdulrasool 08a5ac36b9 libunwind: add missing break statements in EHABI
Add missing break statements identified by static analysis tools.

Patch by Andrii Kurdiumov!

Reviewed By: compnerd, danielkiss

Differential Revision: https://reviews.llvm.org/D107537
2021-08-10 17:53:31 +00:00
Saleem Abdulrasool d6d0b6559e unwind: repair register restoration for OR1K
Currently, OR1K architecture put the program counter at offset 0x128 of
the current `or1k_thread_state_t`. However, the PC is restored after
updating the thread pointer in `r3`, which causes the PC to be fetched
incorrectly.

This patch swaps the order of restoration of `r9` and `r3`, such that
the PC is restored to `r9` using the current thread state.

Patch by Oi Chee Cheung!

Reviewed By: whitequark, compnerd

Differential Revision: https://reviews.llvm.org/D107042
2021-08-02 16:36:37 +00:00
Tom Stellard 08c766a731 Bump the trunk major version to 14
and clear the release notes.
2021-07-27 21:58:25 -07:00
Louis Dionne 21c24ae902 [runtimes] Always build libc++, libc++abi and libunwind with -fPIC
Building the libraries with -fPIC ensures that we can link an executable
against the static libraries with -fPIE. Furthermore, there is apparently
basically no downside to building the libraries with position independent
code, since modern toolchains are sufficiently clever.

This commit enforces that we always build the runtime libraries with -fPIC.
This is another take on D104327, which instead makes the decision of whether
to build with -fPIC or not to the build script that drives the runtimes'
build.

Fixes http://llvm.org/PR43604.

Differential Revision: https://reviews.llvm.org/D104328
2021-07-27 14:19:05 -04:00
Louis Dionne e95cd94f7e [libc++abi/unwind] NFC: Normalize how we set target properties
This is a NFC commit to normalize how we set target properties on the
various runtime targets. A follow-up patch is going to add new properties,
and I wanted that follow-up patch to be cleaner.
2021-07-26 16:38:05 -04:00
Marco Vanotti a085c23aa3 [libunwind] Allow restoring SP while unwinding.
This commit modifies stepWithDwarf allowing for CFI directives to
specify the value of the stack pointer.

Previously, the SP would be unconditionally set to the CFA, because it
(wrongly) stated that the CFA is the stack pointer at the call site of a
function, but that is not always true.

One situation in which that is false, is for example if you have
switched stacks. In that case if you set the CFA to the SP before
switching the stack, the CFA would be far away from where the current
call frame is located.

The CFA always points to the current call frame, and that call frame
could have a CFI directive that specifies how to restore the stack
pointer. If not, it is OK to fallback and set the SP = CFA.

This change sets SP = CFA before restoring the registers during
unwinding, allowing the stack frame to be restored with a value
different than the CFA.

Reviewed By: #libunwind, phosek

Differential Revision: https://reviews.llvm.org/D106626
2021-07-23 12:39:49 -07:00
Louis Dionne 395271ad11 [runtimes] Simplify how we set the target triple
Instead of using TARGET_TRIPLE, which is always set to LLVM_DEFAULT_TARGET_TRIPLE,
use that variable directly to populate the various XXXX_TARGET_TRIPLE
variables in the runtimes.

This re-applies 77396bbc98 and 5099e01568, which were reverted in
850b57c5fb because they broke the build.

Differential Revision: https://reviews.llvm.org/D106009
2021-07-16 10:33:39 -04:00
Louis Dionne a59165b017 [runtimes] Don't try passing --target flags to GCC
When a target triple is specified in CMake via XXX_TARGET_TRIPLE, we tried
passing the --target=<...> flag to the compiler. However, not all compilers
support that flag (e.g. GCC, which is not a cross-compiler). As a result,
setting e.g. LIBCXX_TARGET_TRIPLE=<host-triple> would end up trying to
pass --target=<host-triple> to GCC, which breaks everything because the
flag isn't even supported.

This commit only adds `--target=<...>` & friends to the flags if it is
supported by the compiler.

One could argue that it's confusing to pass LIBCXX_TARGET_TRIPLE=<...>
and have it be ignored. That's correct, and one possibility would be
to assert that the requested triple is the same as the host triple when
we know the compiler is unable to cross-compile. However, note that this
is a pre-existing issue (setting the TARGET_TRIPLE variable never had an
influence on the flags passed to the compiler), and also fixing that is
starting to look like reimplementing a lot of CMake logic that is already
handled with CMAKE_CXX_COMPILER_TARGET.

Differential Revision: https://reviews.llvm.org/D106082
2021-07-15 16:52:02 -04:00
Louis Dionne 0c3401c86e [runtimes] Serialize all Lit params instead of passing them to add_lit_testsuite
add_lit_testsuite() takes Lit parameters passed to it and adds them
to the parameters used globally when running all test suites. That
means that a target like `check-all`, which ends up calling Lit on
the whole monorepo, will see the test parameters for all the individual
project's test suites.

So, for example, it would see `--param std=c++03` (from libc++abi), and
`--param std=c++03` (from libc++), and `--param whatever` (from another
project being tested at the same time). While always unclean, that works
when the parameters all agree. However, if the parameters share the same
name but have different values, only one of those two values will be used
and it will be incredibly confusing to understand why one of the test
suites is being run with the incorrect parameter value.

For that reason, this commit moves away from using add_lit_testsuite()'s
PARAM functionality, and serializes the parameter values for the runtimes
in the generated config.py file instead, which is local to the specific
test suite.

Differential Revision: https://reviews.llvm.org/D105991
2021-07-15 07:53:15 -04:00
Louis Dionne 850b57c5fb [runtimes] Bring back TARGET_TRIPLE
This commit reverts 5099e01568 and 77396bbc98, which broke the build
in various ways. I'm reverting until I can investigate, since that
change appears to be way more subtle than it seemed.
2021-07-14 15:15:22 -04:00
Louis Dionne 5099e01568 [runtimes] Inherit the TARGET_TRIPLE that may be set by LLVM 2021-07-14 14:29:29 -04:00
Louis Dionne 77396bbc98 [runtimes] NFCI: Drop intermediate CMake variable TARGET_TRIPLE
We might as well use the various XXX_TARGET_TRIPLE variables directly.
2021-07-14 10:49:28 -04:00
John Ericson 1e03c37b97 Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all
This is a second attempt at D101497, which landed as
9a9bc76c0e but had to be reverted in
8cf7ddbdd4.

This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is
empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to
"/bin" not "bin" as intended and as was originally.

One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty,
defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach.
But, I think it is more ergonomic to allow those project-specific paths
to be relative the global ones. Also, making install paths absolute by
default inhibits the proper behavior of functions like
`GNUInstallDirs_get_absolute_install_dir` which make relative install
paths absolute in a more complicated way.

Given all this, I will define a function like the one asked for in
https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a
similar use-case).

---

Original message:

Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for
complier-rt, just use it to define variables for the subdirs which
themselves are used.

This preserves compatibility, but later on we might consider getting rid
of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the
subdir variables directly.

---

There was a seaming bug where the (non-Apple) per-target libdir was
`${target}` not `lib/${target}`. I suspect that has to do with the docs
on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no
longer true, so I just went ahead and fixed it, allowing me to define
fewer and more sensible variables.

That last part should be the only behavior changes; everything else
should be a pure refactoring.

---

I added some documentation of these variables too. In particular, I
wanted to highlight the gotcha where `-DSomeCachePath=...` without the
`:PATH` will lead CMake to make the path absolute. See [1] for
discussion of the problem, and [2] for the brief official documentation
they added as a result.

[1]: https://cmake.org/pipermail/cmake/2015-March/060204.html

[2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options

In 38b2dec37e the problem was somewhat
misidentified and so `:STRING` was used, but `:PATH` is better as it
sets the correct type from the get-go.

---

D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands,
it should be feasible to follow both of these up with a simple patch for
compiler-rt analogous to the one for libcxx.

Reviewed By: phosek, #libc_abi, #libunwind

Differential Revision: https://reviews.llvm.org/D105765
2021-07-13 15:21:41 +00:00
Louis Dionne f7d8754312 [runtimes] Move enable_32bit to the DSL
This is necessary for from-scratch configurations to support the 32-bit
mode of the test suite.

Differential Revision: https://reviews.llvm.org/D105435
2021-07-06 08:42:07 -04:00
Nico Weber 7cdd768ac9 [libunwind] reflow some debug logs for better greppability
"bad second level page" and "second level compressed unwind table"
can now be grepped for.

(Also remove one of the two spaces between "second" and "level"
in the second message.)
2021-07-04 17:52:23 -04:00
Louis Dionne c360553c15 [runtimes] Simplify how we specify XFAIL & friends based on the triple
Now that Lit supports regular expressions inside XFAIL & friends, it is
much easier to write Lit annotations based on the triple.

Differential Revision: https://reviews.llvm.org/D104747
2021-07-01 14:03:30 -04:00
Louis Dionne 58a230455b [libc++] Serialize Lit parameters to make them available to from-scratch configs
Before this patch, Lit parameters that were set as a result of CMake
options were not made available to from-scratch configs. This patch
serializes those parameters into the generated lit config file so that
they are available to all configs.

Differential Revision: https://reviews.llvm.org/D105047
2021-06-29 10:51:42 -04:00
Amilendra Kodithuwakku 5636402bc0 [libcxx] Fix exception raised during downstream bare-metal libunwind tests
Fix for the following exception.

AttributeError: 'TestingConfig' object has no attribute 'target_triple'

Related revision: https://reviews.llvm.org/D102012

'TestingConfig' object has no attribute 'target_triple'

Reviewed By: #libunwind, miyuki, danielkiss, mstorsjo

Differential Revision: https://reviews.llvm.org/D103140
2021-06-16 13:35:36 +01:00
Saleem Abdulrasool e03be2efe5 unwind: allow building with GCC
This was regressed in adf1561d6c.  Since gcc does not support
`__has_feature`, this adjusts the build to use the
`__SANITIZE_ADDRESS__` macro which GCC defines to identify if ASAN is
enabled (similar to `__has_feature`).  This allows building libunwind
with gcc again.

Patch by Daniel Levin!

Reviewed By: compnerd

Differential Revision: https://reviews.llvm.org/D104176
2021-06-13 14:44:54 -07:00
Louis Dionne 875ff8e059 [libc++] Enable tests for the experimental library by default
This matches the fact that we build the experimental library by default.
Otherwise, by default we'd be building the library but not testing it,
which is inconsistent.

Differential Revision: https://reviews.llvm.org/D102109
2021-06-02 18:39:27 -04:00
Nico Weber 2fc05fdc15 [libunwind] fix -Wc++98-compat-extra-semi without _LIBUNWIND_HIDE_SYMBOLS 2021-05-31 08:54:53 -04:00
Shoaib Meenai adf1561d6c [libunwind] Inform ASan that resumption is noreturn
If you're building libunwind instrumented with ASan, `_Unwind_RaiseException`
will poison the stack and then transfer control in a manner which isn't
understood by ASan, so the stack will remain poisoned. This can cause
false positives, e.g. if you call an uninstrumented function (so it
doesn't re-poison the stack) after catching an exception. Add a call to
`__asan_handle_no_return` inside `__unw_resume` to get ASan to unpoison
the stack and avoid this.

`__unw_resume` seems like the appropriate place to make this call, since
it's used for resumption by all unwind implementations except SJLJ. SJLJ
uses `__builtin_longjmp` to handle resumption, which is already
recognized as noreturn (and therefore ASan adds the `__asan_handle_no_return`
call itself), so it doesn't need any special handling.

PR32434 is somewhat similar (in particular needing a component built
without ASan to trigger the bug), and rG781ef03e1012, the fix for that
bug, adds an interceptor for `_Unwind_RaiseException`. This interceptor
won't always be triggered though, e.g. if you statically link the
unwinder into libc++abi in a way that prevents interposing the unwinder
functions (e.g. marking the symbols as hidden, using `--exclude-libs`,
or using `-Bsymbolic`). rG53335d6d86d5 makes `__cxa_throw` call
`__asan_handle_no_return` explicitly, to similarly avoid relying on
interception.

Reviewed By: #libunwind, compnerd

Differential Revision: https://reviews.llvm.org/D103002
2021-05-26 09:31:39 -07:00
Louis Dionne 74d096e558 [libc++] Move handling of the target triple to the DSL
This fixes a long standing issue where the triple is not always set
consistently in all configurations. This change also moves the
back-deployment Lit features to using the proper target triple
instead of using something ad-hoc.

This will be necessary for using from scratch Lit configuration files
in both normal testing and back-deployment testing.

Differential Revision: https://reviews.llvm.org/D102012
2021-05-08 11:10:53 -04:00
Xing Xue 8408d3f2d8 [libunwind] NFC: Use macros to accommodate differences in representation of PowerPC assemblers
Summary:
This NFC patch replaces the representation of registers and the left shift operator in the PowerPC assembly code to allow it to be consumed by the GNU flavored assembler and the AIX assembler.

* Registers - change the representation of PowperPC registers from %rn, %fn, %vsn, and %vrn to the register number alone, e.g., n. The GNU flavored assembler and the AIX assembler are able to determine the register kind based on the context of the instruction in which the register is used.

* Left shift operator - use macro PPC_LEFT_SHIFT to represent the left shift operator. The left shift operator in the AIX assembly language is < instead of <<

Reviewed by: sfertile, MaskRay, compnerd

Differential Revision: https://reviews.llvm.org/D101179
2021-05-06 14:33:38 -04:00