Tom Stellard authored Jul 28, 2021 and Silviu Baranga committed Oct 03, 2022

This function is marked with CINDEX_LINKAGE, but was never added to the
export list / linker script.

Reviewed By: jrtc27

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

(cherry picked from commit a4edb2b1ba0bda9042e87ca3f3e1b9f70598df9a)

Richard Smith authored Feb 02, 2022 and Silviu Baranga committed Oct 03, 2022

Consider the form of the first operand of a class assignment not the
second operand when implicitly starting the lifetimes of union members.
Also add a missing check that the assignment call actually came from a
syntactic assignment, not from a direct call to `operator=`.

(cherry picked from commit 30baa5d2a450d5e302d8cba3fc7a26a59d4b7ae1)

Adrian Prantl authored Dec 10, 2021 and Silviu Baranga committed Oct 03, 2022

DwarfExpression::addUnsignedConstant(const APInt &Value) only supports
wider-than-64-bit values when it is used to emit a top-level DWARF
expression representing the location of a variable. Before this change,
it was possible to call addUnsignedConstant on >64 bit values within a
subexpression when substituting DW_OP_LLVM_arg values.

This can trigger an assertion failure (e.g. PR52584, PR52333) when it
happens in a fragment (DW_OP_LLVM_fragment) expression, as
addUnsignedConstant on >64 bit values splits the constant into separate
DW_OP_pieces, which modifies DwarfExpression::OffsetInBits.

This change papers over the assertion errors by bailing on overly wide
DW_OP_LLVM_arg values. A more comprehensive fix might be to be to split
wide values into pointer-sized fragments.

[0] https://github.com/llvm/llvm-project/blob/e71fa03/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp#L799-L805

Patch by Ricky Zhou!

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

(cherry picked from commit c7c84b90879f0252c58894f70d2a19fc4c01cf64)

Richard Smith authored Mar 31, 2022 and Silviu Baranga committed Oct 03, 2022

lexically contains a mention of the pack.

Systematically distinguish between syntactic and semantic references to
packs, especially when propagating dependence from a type into an
expression. We should consult the type-as-written when computing
syntactic dependence and should consult the semantic type when computing
semantic dependence.

Fixes #54402.

(cherry picked from commit f1b0a4fc540f986372f09768c325d505b75b414d)

We need the size of the capability to match exactly the size of the
memory transfer to do this.

For any representable length of the form (1 << 12) - 1) << (E + 3), i.e.
the largest representable length for an exponent E, RRLEN and RRMASK as
defined in Morello will incorrectly round the length up to the next
representable one. On the surface this might not be an issue, as one
might imagine it just results in a bit of redundant padding in edge
cases, but it is in fact problematic for software written against the
generic CHERI C interfaces. For example, a common way to assert that a
length is representable is cheri_representable_length(x) == x, which is
used in various places in CheriBSD, but this fails in the case that x is
one of the special values. In particular, this has been seen to happen
in the CheriBSD kernel's ELF image activator, since we round and align
the start and end addresses for the mapped region to be representable
and later assert this has been done, but very occasionally executables
are produced that trip this up and panic the kernel. One could go add a
workaround to every piece of software that requires the intrinsics to be
exact, but this quickly becomes tedious and may not catch all such
cases, leaving latent hard-to-trigger bugs on just Morello.

Instead, make the Morello implementation of the intrinsics conform to
the CHERI contract by expanding them to a multi-instruction sequence
that detects potentially-problematic cases and fixes them to be what
they should be. For efficiency, however, we leave DYNAMIC_STACKALLOC as
padded more than needed; note that we already have a second SCBNDS for
this case that takes the original unpadded length and so we will still
get the tighter bounds on the capability, just a bit of padding after
the top.

For now the inexact LLVM intrinsics are not made available to Clang, but
these should be added once a suitable name has been agreed upon (such as
__builtin_morello_*_inexact to match the LLVM names chosen here, which
should not be considered stable).

Distinguish between purecap and hybrid based on the existence of the
EF_AARCH64_CHERI_PURECAP flag in the binary. This information is passed
into the ArchSpec and used when determining the size of a pointer. Note
that even with this patch we still don't have a fully consistent
handling of pointers vs addresses in lldb, so certain things might still
be broken. However, we can now enable one of the end-to-end tests for
hybrid mode. It used to pass only for purecap because we were making an
assumption about certain pointers being capabilities.

* Trim potential trailing / on the input ANDROID_OUT

branches

We now generate the expected relocation for a function instead of a
relocation against section+offset. This ensures that compiling with
-ffunction-sections no longer creates relocations without the LSB set.

Alex Richardson authored Aug 25, 2022 and Alex Richardson committed Aug 26, 2022

While this does not matter for most targets, when building for Arm Morello,
we have to mark the symbol as a function and add size information, so that
LLD can correctly evaluate relocations against the local symbol.
Since Morello is an out-of-tree target, I tried to reproduce this with
in-tree backends and with the previous reviews applied this results in
a noticeable difference when targeting Thumb.

Background: Morello uses a method similar Thumb where the encoding mode is
specified in the LSB of the symbol. If we don't mark the target as a
function, the relocation will not have the LSB set and calls will end up
using the wrong encoding mode (which will almost certainly crash).

Reviewed By: MaskRay

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

(cherry picked from commit 0483b008759b566984f040269b7a90210922a145)

When calling a dso_local function, we end up creating a call against the
.Lfoo$local label. This might be converted to a relocation against a
section if there is such a matching one (which is a lot more likely with
-ffunction-sections). LLD will later infer that a C64->A64 thunk is needed
and generate an incorrect binary.

Markus Böck authored Jan 06, 2022 and Silviu Baranga committed Aug 17, 2022

-Wdeclaration-after-statement currently only outputs an diagnostic if the user is compiling in C versions older than C99, even if the warning was explicitly requested by the user.
This patch makes the warning also available in later C versions. If the C version is C99 or later it is simply a normal warning that is disabled by default (as it is valid C99) and has to be enabled by users. In older versions it remains an extension warning, and therefore affected by -pedantic.

The above behaviour also matches GCCs behaviour.

Fixes https://bugs.llvm.org/show_bug.cgi?id=51931

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

https://reviews.llvm.org/D114787

using a pseudoinst.

This guarantees that MachineLICM can't hoist the adrp
and not the ldr.

We were doing this at ISel which is way too early as
it can interfere with MachineLICM. Additionally
this adds an add instruction which is not always a win.

addresses for aliases in purecap.

The motivation is that the global merge pass will replace
globals with aliases to a merged global.

The merged global address is produced by loading a capability
from a pc-relative relocation (same as before).

Safe loads/stores can use the merged global directly. Unsafe
uses still need to produce the address of the global by doing
a load from the capability table.

For now this just does the merging, and for purecap we're
replacing the old globals with the new aliases. This doesn't
change codegen (we're still acccessing globals via loads),
but it will enable future optimizations.

Some notable changes to the globals merge pass:
  - We're attempting to pad globals to make capabilies to the
    emitted aliases representable. This doesn't do anything,
    since the maximum size of the merged global is 4096, but
    it's nice to have this in place.
  - We're replacing the old globals with aliases to the merged
    global. This keeps size information and we can consume it
    in future optimizations.
  - For purecap we merge BSS globals with non-BSS ones, which
    means globals that were in .bss now end up in .data. For
    purecap this is worth it as it's going to remove some
    loads/stores

AArch64SandboxGlobalsOpt also now processes aliases as well.
The metadata format for determining the index of the capability
table for a global has changed since global aliases cannot
attach metadata.

Sometimes the binaries might get left behind from a previous (possibly
interrupted) run, which causes adb to error out when trying to upload
them. This patch removes them if they already exist on the device, so we
can test with up-to-date binaries.

The end-to-end lldb tests used to be run only under the purecap ABI.
This patch makes it possible to build and run a test both as purecap and
as hybrid. It also enables most tests to be run for both ABIs. In order
to do so, it sometimes adds `__capability` qualifiers to pointers (e.g.
in order to trigger a capability fault even under the hybrid ABI).

See the updates to the README for the low level details.

Mention that we can run the end-to-end tests either with an FVP model or
a board.

Whilst these are legacy and both GCC and Clang want code to migrate away
from them, many open-source projects make use of them rather than the
GNU __atomic/Clang __c11_atomic intrinsics or standard C(++)11 atomics.
Add support for using them, with both overloaded and explicit forms.

Upstream Clang only supports this extension on ints, as does CHERI LLVM.
For some unknown reason Morello LLVM has overloaded this since the first
commit, but this does not seem necessary. Real world code won't be using
it on anything other than ints as a result, and so it's already not
usable on pointers, thus not a concern for CHERI that there's no
capability version. It's also unlikely anyone's really using it since
it's a Clang extension for the deprecated __sync builtins. Upstreaming
the overloading might make sense if the __sync builtins weren't
deprecated, but nobody should be writing new code with them when better
alternatives exist (GNU __atomic and Clang __c11_atomic intrinsics or
standard C(++)11 atomics).

There is already another declaration just below; this must have been
mismerged at some point in the past. Deleting the declaration removes
this unnecessary diff to CHERI LLVM.

This allows for capability references and (unsigned) __intcap
respectively. This also allows m to appear anywhere in the postfix
modifiers, not just the first one.

Note that the im syntax is a bit of a hack; ideally there would be a
prefix modifier for __intcap just as there is for __int128, mirroring
the C grammar, but that requires stealing more encoding space than
repurposing the existing m.

This will ensure we don't break them when adding capability support,
just like we have Clang __c11 and GNU __atomic i128 tests.

Whilst 8b6818e1 added them for capabilities, it failed to do so for
i128, so add them for completeness.

Now this is supported by the backends we don't need to force use of the
libcalls. I'm not sure if hasBuiltinAtomic is quite the right shape, but
this is better than having cheriCapabilityAtomicNeedsLibcall on the side
over in CodeGen's TargetInfo rather than Basic's.

For atomics on integers (or pointers represented as integers) the
arguments are canonicalised to the underlying integer type. We don't
currently do this for capability arguments, so the libcall ends up being
used with capability types other than i8 addrspace(200)* and we end up
bitcasting the libcall itself when there are conflicting uses.

Note that some of the weird comment placement and reformatting is to
reduce diffs to upstream now that we canonicalise in all cases.

This has always been #if'ed out (initially NOTYET, then 0), and dates
back to 2017 (38bb492e) when we had poor support for atomics on
capabilities, not distinguishing them from integers properly in paths
like this.

These now work, and generate decent code for purecap CHERI-RISC-V with
RVA present. Libcalls and hybrid are rather inefficient, as is
CHERI-MIPS, but those are less interesting and can be improved upon
later if anyone cares.

Ideally we would have a proper implementation of these with an inlined
ll/sc loop like CHERI-RISC-V (and CHERI-MIPS for i32/i64) but it's not
worth it when CHERI-MIPS is EOL'ed; this is sufficient to make code
generation work so we can enable the CHERI-Generic tests.

These operate on the address, so we perform the usual address extraction
and re-injection sequence (with additional pain due to typed pointers)
as a recursive wrapper around the existing function.

This also fixes an old TODO in MipsInstrCheri to move the ones there to
TargetSelectionDAG.td, and cleans up TargetSelectionDAG.td's _cap
definitions to look more like their non-_cap counterparts.

Using a VT rather than an integer width everywhere makes things much
saner and allows for a common implementation that works for both
integers and capabilities. This pattern will be followed for other AMOs
so as to reduce code explosion.

This removes redundant attributes, LLVM AsmWriter debug comments and
basic block labels (when only one basic block exists in the function;
even if unreferenced I have kept the entry labels for multi-block
functions) from the tests to make them cleaner and more concise. No
functional changes to the tests intended. Note that, when unnamed, the
entry basic block will be automatically named %n, typically %0, so this
perturbs the numbering of later variables.

Of the binary operators, only __atomic_fetch_add/sub worked. Whilst
__atomic_add/sub_fetch were marked as needing a libcall, the libcall
emission code could not correctly handle the post-op versions, trying to
perform integer operations on pointers, and all other binary operators
were left unknown at the cheriCapabilityAtomicNeedsLibcall level, giving
llvm_unreachable errors.

The implementation of cheriCapabilityAtomicNeedsLibcall is restructured
so it will give warnings when new atomics are added that we don't yet
handle. Whilst we don't care about OpenCL atomics, they reuse almost all
the logic for the C11 atomics (even going so far as to use _Atomic in
their error messages despite that not existing in OpenCL), and can even
be used from C, but we can't actually test them at the moment as far as
I can tell since there's no way to construct an atomic pointer type.
However, with some local hackery, I can verify they appear to work as
they should do if supported.

Fixes https://github.com/CTSRD-CHERI/llvm-project/issues/625