1. 03 Oct, 2022 4 commits
    • Tom Stellard's avatar
      libcang: Add missing function to libclang.map · 1c2662b6
      Tom Stellard authored and Silviu Baranga's avatar Silviu Baranga committed
      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's avatar
      PR45879: Fix assert when constant evaluating union assignment. · ec844a8e
      Richard Smith authored and Silviu Baranga's avatar Silviu Baranga committed
      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's avatar
      [DwarfDebug] Refuse to emit DW_OP_LLVM_arg values wider than 64 bits · 78397683
      Adrian Prantl authored and Silviu Baranga's avatar Silviu Baranga committed
      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's avatar
      An expression should only contain an unexpanded parameter pack if it · f4fce779
      Richard Smith authored and Silviu Baranga's avatar Silviu Baranga committed
      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)
  2. 30 Sep, 2022 1 commit
  3. 28 Sep, 2022 1 commit
    • Jessica Clarke's avatar
      [Morello] Work around RRLEN/RRMASK ISA quirk · d755e377
      Jessica Clarke authored
      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).
  4. 16 Sep, 2022 1 commit
    • Diana Picus's avatar
      [Morello][lldb] Read the ABI from ELF · f37aa851
      Diana Picus authored
      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.
  5. 15 Sep, 2022 1 commit
  6. 30 Aug, 2022 1 commit
  7. 26 Aug, 2022 3 commits
    • Alex Richardson's avatar
      [Morello] Update test after upstream cherry-pick · fafe622f
      Alex Richardson authored
      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's avatar
      Mark the $local function begin symbol as a function · 8524e56f
      Alex Richardson authored and Alex Richardson's avatar Alex Richardson committed
      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)
    • Alex Richardson's avatar
      [Morello] Baseline test for incorrect relocation with -ffunction-sections · e179980e
      Alex Richardson authored
      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.
  8. 17 Aug, 2022 2 commits
  9. 27 Jul, 2022 1 commit
  10. 26 Jul, 2022 1 commit
  11. 22 Jul, 2022 2 commits
    • Silviu Baranga's avatar
      [Morello] Add a pass to change the way we are creating · 8646277e
      Silviu Baranga authored
      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.
    • Silviu Baranga's avatar
      [Morello] Enable global merging for purecap. · 5f02f5b7
      Silviu Baranga authored
      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
      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.
  12. 21 Jul, 2022 3 commits
    • Diana Picus's avatar
      [Morello][lldb] Clean binaries in test runner · 94721dfc
      Diana Picus authored
      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.
    • Diana Picus's avatar
      [Morello][lldb] Run end-to-end tests with 2 ABIs · 01fba3d7
      Diana Picus authored
      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.
    • Diana Picus's avatar
      [Morello][lldb] Update comments. NFC · 69cb6a9d
      Diana Picus authored
      Mention that we can run the end-to-end tests either with an FVP model or
      a board.
  13. 18 Jul, 2022 19 commits
    • Jessica Clarke's avatar
      [clang] Add support for legacy __sync builtins with capability types · aba2e084
      Jessica Clarke authored
      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.
    • Jessica Clarke's avatar
      [clang] Remove unnecessary __sync_fetch_and_(u)min/max overload · 62e8fb92
      Jessica Clarke authored
      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).
    • Jessica Clarke's avatar
      [clang][NFC] Remove duplicate forward declaration · 250ed008
      Jessica Clarke authored
      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.
    • Jessica Clarke's avatar
      [clang] Permit &m and im like *m in builtin type strings · dc239c2b
      Jessica Clarke authored
      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.
    • Jessica Clarke's avatar
    • Jessica Clarke's avatar
      [clang] sync-atomic-i128.c: Add tests for legacy __sync atomics on i128 · 84904dec
      Jessica Clarke authored
      This will ensure we don't break them when adding capability support,
      just like we have Clang __c11 and GNU __atomic i128 tests.
    • Jessica Clarke's avatar
      [clang] gnu-atomic-i128.c: Add missed nand tests · 5d0719c1
      Jessica Clarke authored
      Whilst 8b6818e1 added them for capabilities, it failed to do so for
      i128, so add them for completeness.
    • Jessica Clarke's avatar
      [clang] Generate atomicrmw instructions for capability value atomics · 3613d756
      Jessica Clarke authored
      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.
    • Jessica Clarke's avatar
      [clang] Canonicalise capability atomic values like integers · 3f99c703
      Jessica Clarke authored
      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.
    • Jessica Clarke's avatar
      [clang][Mips] Drop pointless hasBuiltinAtomic override · 5e23208b
      Jessica Clarke authored
      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.
    • Jessica Clarke's avatar
      [CHERI-Generic] Enable capability value atomic RMW tests · f50d75be
      Jessica Clarke authored
      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.
    • Jessica Clarke's avatar
      [CHERI-MIPS] Enable expansion of non-xchg capability atomic RMW · bacfe715
      Jessica Clarke authored
      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.
    • Jessica Clarke's avatar
      [AtomicExpandPass] Support expanding RMW ops on capabilities · e2da526d
      Jessica Clarke authored
      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.
    • Jessica Clarke's avatar
    • Jessica Clarke's avatar
      [Target][NFC] Define full set of _cap SDNodes and PatFrags · a90df556
      Jessica Clarke authored
      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.
    • Jessica Clarke's avatar
      [CHERI-RISC-V][NFC] Reduce code duplication for cmpxchg of capabilities · 05548c4c
      Jessica Clarke authored
      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.
    • Jessica Clarke's avatar
    • Jessica Clarke's avatar
      [CHERI-Generic] Clean up lint from many tests · 01f8f1d8
      Jessica Clarke authored
      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.
    • Jessica Clarke's avatar
      [clang] Support remaining GNU __atomic builtins on capabilities · 59004389
      Jessica Clarke authored
      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