[libc++] Fix deployment target Lit features (#94791)

We were not making any distinction between e.g. the "Apple-flavored"
libc++ built from trunk and the system-provided standard library on
Apple

[libc++] Fix deployment target Lit features (#94791)

We were not making any distinction between e.g. the "Apple-flavored"
libc++ built from trunk and the system-provided standard library on
Apple platforms. For example, any test that would be XFAILed on a
back-deployment target would unexpectedly pass when run on that
deployment target against the tip of trunk Apple-flavored libc++. In
reality, that test would be expected to pass because we're running
against the latest libc++, even if it is Apple-flavored.

To solve this issue, we introduce a new feature that describes whether
the Standard Library in use is the one provided by the system by
default, and that notion is different from the underlying standard
library flavor. We also refactor the existing Lit features to make a
distinction between availability markup and the library we're running
against at runtime, which otherwise limit the flexibility of what we can
express in the test suite. Finally, we refactor some of the
back-deployment versions that were incorrect (such as thinking that LLVM
10 was introduced in macOS 11, when in reality macOS 11 was synced with
LLVM 11).

Fixes #82107

show more ...

[libc++] Use the stdlib=<LIB> Lit feature instead of use_system_cxx_lib

The use_system_cxx_lib Lit feature was only used for back-deployment
testing. However, one immense hole in that setup was that

[libc++] Use the stdlib=<LIB> Lit feature instead of use_system_cxx_lib

The use_system_cxx_lib Lit feature was only used for back-deployment
testing. However, one immense hole in that setup was that we didn't
have a proper way to test Apple's own libc++ outside of back-deployment,
which was embodied by the fact that we needed to define _LIBCPP_DISABLE_AVAILABILITY
when testing (see change in libcxx/utils/libcxx/test/params.py).

This led to the apple-system testing configuration not checking for
availability markup, which is obviously quite bad since the library
we ship actually has availability markup.

Using stdlib=<VENDOR>-libc++ instead to encode back-deployment restrictions
on tests is simpler and it makes it possible to naturally support tests
such as availability markup checking even in the tip-of-trunk Apple-libc++
configuration.

Differential Revision: https://reviews.llvm.org/D146366

show more ...

[libunwind] Ensure test/libunwind_01.pass is not completely inlined

By adding noinline and calling fprintf before returning we ensure that
every function will have a distinct call frame and that the

[libunwind] Ensure test/libunwind_01.pass is not completely inlined

By adding noinline and calling fprintf before returning we ensure that
every function will have a distinct call frame and that the return address
will always be saved instead of saving the target in main as the result.

Before this change all backtraces were always backtrace -> main -> _start,
i.e. always exactly three entries. This happenend because all calls were
inlined in main() and the test just happenend to pass because there is at
least _start before main.

I found this while fixing some bugs in libunwind for CHERI and noticed that
the test was passing even though the code was completely broken.

Obtained from: https://github.com/CTSRD-CHERI/llvm-project

Reviewed By: #libunwind, ldionne, MaskRay

Differential Revision: https://reviews.llvm.org/D126611

show more ...

[libunwind] Tidy-up the testing configuration for libunwind

Start testing Apple backdeployment with older libunwinds, and stop
explicitly specifying the libunwind testing config, since it is
already

[libunwind] Tidy-up the testing configuration for libunwind

Start testing Apple backdeployment with older libunwinds, and stop
explicitly specifying the libunwind testing config, since it is
already selected correctly by default.

Differential Revision: https://reviews.llvm.org/D126470

show more ...

[libunwind] Add missing licenses in test files

[libc++] Add a CI job running MSAN

For some reason, we've been going without a MSAN CI job, even though
even run-buildbot defined a generic-msan job. This must have been an
oversight that went unnot

[libc++] Add a CI job running MSAN

For some reason, we've been going without a MSAN CI job, even though
even run-buildbot defined a generic-msan job. This must have been an
oversight that went unnoticed. Thanks to @EricWF for the catch.

Differential Revision: https://reviews.llvm.org/D120851

show more ...

[libunwind] Fix testing with sanitizers enabled

When testing with sanitizers enabled, we need to link against a plethora
of system libraries. Using `-nodefaultlibs` like we used to breaks this,
and

[libunwind] Fix testing with sanitizers enabled

When testing with sanitizers enabled, we need to link against a plethora
of system libraries. Using `-nodefaultlibs` like we used to breaks this,
and we would have to add all these system libraries manually, which is
not portable and error prone. Instead, stop using `-nodefaultlibs` so
that we get the libraries added by default by the compiler.

The only caveat with this approach is that we are now relying on the
fact that `-L <path-to-local-libunwind>` will cause the just built
libunwind to be selected before the system implementation (either of
libunwind or libgcc_s.so), which is somewhat fragile.

This patch also turns the 32 bit multilib build into a soft failure
since we are in the process of removing it anyway, see D114473 for
details. This patch is incompatible with the 32 bit multilib build
because Ubuntu does not provide a proper libstdc++ for 32 bits, and
that is required when running with sanitizers enabled.

Differential Revision: https://reviews.llvm.org/D114385

show more ...

[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 i

[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

show more ...

[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 n

[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

show more ...

[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.or

[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

show more ...

[runtimes] Use int main(int, char**) consistently in tests

This is needed when running the tests in Freestanding mode, where main()
isn't treated specially. In Freestanding, main() doesn't get mangl

[runtimes] Use int main(int, char**) consistently in tests

This is needed when running the tests in Freestanding mode, where main()
isn't treated specially. In Freestanding, main() doesn't get mangled as
extern "C", so whatever runtime we're using fails to find the entry point.

One way to solve this problem is to define a symbol alias from __Z4mainiPPc
to _main, however this requires all definitions of main() to have the same
mangling. Hence this commit.

show more ...

[libunwind] Adjust libunwind_01.pass.cpp test for ARM EHABI

ARM EHABI unwinding tables only store the start address of each function, so the
last function is assumed to cover the entire address spac

[libunwind] Adjust libunwind_01.pass.cpp test for ARM EHABI

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

show more ...

Unwind: prevent unw_get_proc_info from returning stale data

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 pre

Unwind: prevent unw_get_proc_info from returning stale data

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

show more ...

libunwind: Fix unw_step() for ARM EHABI.

This commit fixes the unw_step() for ARM EHABI. However, this commit
also changes the implementation details for ARM EHABI.

The first change is that the pe

libunwind: Fix unw_step() for ARM EHABI.

This commit fixes the unw_step() for ARM EHABI. However, this commit
also changes the implementation details for ARM EHABI.

The first change is that the personality function should call
__gnu_unwind_frame() for default (or de facto) frame unwinding based on
the ARM-defined unwind opcode. The function __gnu_unwind_frame() will
in turn calls unw_step() which actually unwinds the frame.

The second change is that the implementation _Unwind_Backtrace() should
no longer calls unw_step() to unwind the frame; since according to ARM
EHABI, the personality function should unwind the frame for us.

Special thanks to Anton for helpful suggestion on the initial version of
this patch.

llvm-svn: 238560

show more ...