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
This patch removes the ability to build the runtimes in the 32 bit
multilib configuration, i.e. using -m32. Instead of doing this, one
should cross-compile the runtimes for the appropriate target triple,
like we do for all other triples.
As it stands, -m32 has several issues, which all seem to be related to
the fact that it's not well supported by the operating systems that
libc++ support. The simplest path towards fixing this is to remove
support for the configuration, which is also the best course of action
if there is little interest for keeping that configuration. If there
is a desire to keep this configuration around, we'll need to do some
work to figure out the underlying issues and fix them.
Differential Revision: https://reviews.llvm.org/D114473
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
After recent changes to the Docker image, all hell broke loose and the
CI started failing. This patch marks a few tests as unsupported until
we can figure out what the issues are and fix them.
In the future, it would be ideal if the nodes could pick up the Dockerfile
present in the revision being tested, which would allow us to test changes
to the Dockerfile in the CI, like we do for all other code changes.
Differential Revision: https://reviews.llvm.org/D112737
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
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
The LIT substitutions used in libunwind are the same as those from
libc++, and we forgot to update the libunwind tests after the libc++
substitutions started being delimited by braces.
parseInstructions() doesn't always process the whole set of DWARF
instructions for a frame. It will stop once the target PC is reached, or
if malformed instructions are found. So, for example, if we have an
instruction sequence like this:
```
<start>
...
DW_CFA_remember_state
...
DW_CFA_advance_loc past the location we're unwinding at (pcoffset in parseInstructions() main loop)
...
DW_CFA_restore_state
<end>
```
... the saved state will never be freed, even though the
DW_CFA_remember_state opcode has a matching DW_CFA_restore_state later
in the sequence.
This change adds code to free whatever is left on rememberStack after
parsing the CIE and the FDE instructions.
Differential Revision: https://reviews.llvm.org/D66904
Louis Dionne