[all-commits] [llvm/llvm-project] b6a939: [NFC][libunwind] Fix uintptr_t vs size_t confusion...

[Jessica Clarke via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b6a93967d9c11e79802b5e75cec1584d6c8aa472
      https://github.com/llvm/llvm-project/commit/b6a93967d9c11e79802b5e75cec1584d6c8aa472
  Author: Jessica Clarke <jrtc27 at jrtc27.com>
  Date:   2022-01-19 (Wed, 19 Jan 2022)

  Changed paths:
    M libunwind/src/AddressSpace.hpp
    M libunwind/src/DwarfParser.hpp

  Log Message:
  -----------
  [NFC][libunwind] Fix uintptr_t vs size_t confusion for lengths

These two are not conceptually the same; the former is a pointer shoved
in an integer, the latter is an offset or length. On the architectures
supported by libunwind, these two have the same underlying type, namely
unsigned int on ILP32, unsigned long on LP64 and unsigned long long on
LLP64. However, on CHERI, and thus Arm's Morello, they are not the same,
as pointers are hardware capabilities that carry additional metadata
including bounds and permissions, which is preserved in uintptr_t but
not in size_t. Thus, fix all length variables to be of type size_t not
uintptr_t, as we have done downstream for a while in CHERI LLVM but did
not get round to upstreaming.

Note that dyld_unwind_sections is currently defined in Apple's headers
as genuinely using uintptr_t to represent lengths. This is a bad API and
should be fixed, which would be totally API and ABI compatible due to
size_t and uintptr_t being the same type on all supported Apple systems,
but our definition is left matching theirs until such a time as they fix
their bogus types.

This is intended to be an NFC change on all architectures supported by
LLVM upstream, only being a functional change for CHERI downstream in
CHERI LLVM.