GitLab

Previously, -mabi=purecap required -march=morello+c64. Now you can
always use -march=morello and just toggle the encoding mode
automatically with -mabi=purecap vs -mabi=aapcs. Adding an explicit
+a64c/+c64/+noa64c to -march and using an incompatible ABI remains an
error, and is now diagnosed in the driver rather than being a fatal
error in the backend if you specify an incompatible combination
(including omitting required arguments).

Closes: #13

When spilling capabilities to the stack we can end up generating a
PCapLoadImmPre instruction with a capsp register class, which is invalid.
Use the same approach as the code for GPR64 to avoid this error.

When spilling capabilities to the stack we can end up generating a
PCapLoadImmPre instruction with a capsp register class, which is invalid.
This baseline test (with machine verifier disabled) shows the incorrect
code generation.

and LIBUNWIND_INSTALL_SHARED_LIBRARY options.

This reverts commit 48ad446a.

This reverts commit 48ad446a.

Visiting the ADD can cause the PTRADD itself to become a deleted node.
This can be avoided by doing things the more normal way, namely using a
HandleSDNode to hold onto the ADD node we're visiting and then creating
the PTRADD when we need it, not creating it early, poking at it after
visiting the ADD assuming it's still there, and re-creating it if the
ADD node was changed but not RAUW'd.

Reducing with CVise is noticeably faster than using CReduce, so prefer it
if it can be found in $PATH.

CVise is an almost entierly compatible faster version of CReduce, this
change makes some minor changes to allow using it instead of CReduce.

subrepo:
  subdir:   "libunwind"
  merged:   "ecce9e8c2e6a"
upstream:
  origin:   "https://github.com/CTSRD-CHERI/libunwind"
  branch:   "monorepo-mirror"
  commit:   "ecce9e8c2e6a"
git-subrepo:
  version:  "0.4.1"
  origin:   "???"
  commit:   "???"

Commit b4bb2ea3 removed the space to
store DDC in the unw_context_t, but the assembly was not deleted, so we
still store it to the one-past-the-end offset 768. This results in a
bounds violation when called from _Unwind_RaiseException(). We did not
notice this initially since it was only added to cheribsd in January
with https://github.com/CTSRD-CHERI/cheribsd/commit/898cdc78310c1a805fdde2188ecd5590f3f69d37.
I've also updated _ZN9libunwind15Registers_riscv6jumptoEv, which should
have the same problem.


Fixes: https://github.com/CTSRD-CHERI/llvm-project/pull/515

This is a repeat of the upstream PseudoLA* changes for their CHERI
counterparts.

Since we mark the pseudos as mayLoad but do not provide any MMOs,
isSafeToMove conservatively returns false, stopping MachineLICM from
hoisting the instructions. PseudoLA_TLS_GD does not actually expand to a
load, so stop marking that as mayLoad to allow it to be hoisted, and for
the others make sure to add MMOs during lowering to indicate they're GOT
loads and thus can be freely moved.

Fixes https://github.com/llvm/llvm-project/issues/54372

Reviewed By: MaskRay, arichardson

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

(cherry picked from commit 659363c0ccfb36a0cb6ad70b9ea262b66296ed84)

Only PseudoLLA is currently hoisted; this will be fixed in a subsequent
commit.

(cherry picked from commit 883f755639462d3c2cb6ec22bcfb7ee769fb7715)

As discussed in https://reviews.llvm.org/D104830, this commit was a bad
idea, breaking ctfconvert on AArch64, and has been reverted in FreeBSD
LLVM. Getting it fixed properly upstream continues to be a drag, with
https://reviews.llvm.org/D116774 still stalled, so just revert this
until upstream sorts things out. -fsanitize=cfi-icall is not something
we care about.

This reverts commit e655e74a.

Using the out-of-line LSE atomics helpers for AArch64 on FreeBSD also
requires adding support for initializing __aarch64_have_lse_atomics
correctly. On Linux this is done with getauxval(3), on FreeBSD with
elf_aux_info(3), which has a slightly different interface.

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

(cherry picked from commit 7dbbb5d3a46e1526cfa126ae02a5856d7ce0fda9)

This matches other section lengths in UnwindInfoSections and avoids
ambiguous provenance in FrameHeaderCache::HighPC().

subrepo:
  subdir:   "compiler-rt"
  merged:   "5f9dcf36d439"
upstream:
  origin:   "https://github.com/CTSRD-CHERI/compiler-rt"
  branch:   "monorepo-mirror"
  commit:   "5f9dcf36d439"
git-subrepo:
  version:  "0.4.1"
  origin:   "???"
  commit:   "???"

subrepo:
  subdir:   "libcxx"
  merged:   "f040ad6b1612"
upstream:
  origin:   "https://github.com/CTSRD-CHERI/libcxx"
  branch:   "monorepo-mirror"
  commit:   "f040ad6b1612"
git-subrepo:
  version:  "0.4.0"
  origin:   "???"
  commit:   "???"

subrepo:
  subdir:   "libunwind"
  merged:   "870cf88ed5be"
upstream:
  origin:   "https://github.com/CTSRD-CHERI/libunwind"
  branch:   "monorepo-mirror"
  commit:   "870cf88ed5be"
git-subrepo:
  version:  "0.4.1"
  origin:   "???"
  commit:   "???"

As with 32-bit Arm we need to mask off the LSB, otherwise if the PC is
at the end of the function (which does legitimately happen; on AArch64
calls to noreturn functions, including __cxa_throw, will still use a bl
but have no code afer them) the LSB pushes it past the end and thus we
find the FDE for the next function rather than the current function.

Currently, code such as:

  %0 = alloca
  %1 = bitcast ... %0 to i8 addrspace(200)*
  %2 = @llvm.lifetime.start.p200i8(..., %1)
  ...
  unsafe use of %1

causes problems for CheriBoundAllocas. Since the bitcast has an unsafe
use, we end up bounding the bitcast input (trying to maintain the
illusion that the alloca itself does the bounding). However, since in
this specific case the unsafe array uses the alloca as an i8 pointer,
just as the lifetime start/end arguments, they reuse the same bitcast,
and so we end up bounding the input to the lifetime markers.

We could try and copy the subtrees that have unsafe uses whilst leaving
the lifetime markers untouched, but that is complex and fragile.
Instead, for static allocas, we already have a special intrinsic we can
key off in ValueTracking so that the lifetime markers can peek through
the bounding, so do so, and add a separate one for dynamic allocas
(since some places assume that cheri_bounded_stack_cap will take a
FrameIndex operand).

It's never set to anything other than true, and in the next commit using
the special intrinsic will become mandatory for correctness.

We can no longer just blindly run all the UTC scripts one by one, since
both update_llc_test_checks.py and update_mir_test_checks.py will claim
llc RUN lines and delete the other's output. Thus this involves adding a
new CHERI-GENERIC-UTC: directive that explicitly requests the set of UTC
scripts to run, defaulting to the existing llc+opt if not specified.

Note this part of the C++ parser gets used even for C.

Closes: #606

Note that this function is only ever used for consistency checking in an
assertions build.

Closes: #605

Abusing CurrentFnSymForSize, which is CurrentFnBegin in this context,
almost works via a symbol assignment, except that this causes issues for
Morello downstream, since, although we set CurrentFnLocalForEH's type to
be a function, its value is CurrentFnBegin's which is not set to be a
function, and so it does not have the LSB set to indicate C64. Whether
this is correct behaviour or not is questionable, but the current
implementation is a bit hacky anyway.

Since there is no appropriate label to use in the general case, this
introduces a new label. Its value logic follows that of CurrentFnBegin,
but its size and type logic follows that of CurrentFnSym.

This was added in 2017 in 4ae1b6a2 without justification. There is
already an assertion upstream that UnwindCursor does not exceed
unw_cursor_t's size and, more recently, alignment, and the stronger
assertion that they're always equal does not hold on i386, where
unw_cursor_t is bigger than UnwindCursor. Not to mention that the assert
should have been written as an inline static_assert like the others, not
with this weird helper function.