[builtins] Fix integer/pointer confusion in gcc_personality_v0.c

This fixes the implementation for architectures like CHERI with strong
pointer provenance (pointers, and thus uintptr_t, are represented as
hardware capabilities). Specifically, adding two uintptr_t's together
(as is done for `start + length` and `funcStart + landingPad`) has
ambiguous provenance, whereas using a plain integer (such as size_t) for
the offset operand does not. Also, readULEB128 is creating a plain
integer, not a pointer.

On all currently-supported architectures this should be an NFC, as
size_t and uintptr_t end up being the same underlying plain integer
type.

Reviewed By: MaskRay

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

compiler-rt/lib/builtins/gcc_personality_v0.c

@@ -43,9 +43,9 @@
 #define DW_EH_PE_indirect 0x80 // gcc extension
 
 // read a uleb128 encoded value and advance pointer
-static uintptr_t readULEB128(const uint8_t **data) {
-  uintptr_t result = 0;
-  uintptr_t shift = 0;
+static size_t readULEB128(const uint8_t **data) {
+  size_t result = 0;
+  size_t shift = 0;
   unsigned char byte;
   const uint8_t *p = *data;
   do {
@@ -211,8 +211,8 @@ COMPILER_RT_ABI _Unwind_Reason_Code __gcc_personality_v0(
   const uint8_t *p = callSiteTableStart;
   while (p < callSiteTableEnd) {
     uintptr_t start = readEncodedPointer(&p, callSiteEncoding);
-    uintptr_t length = readEncodedPointer(&p, callSiteEncoding);
-    uintptr_t landingPad = readEncodedPointer(&p, callSiteEncoding);
+    size_t length = readEncodedPointer(&p, callSiteEncoding);
+    size_t landingPad = readEncodedPointer(&p, callSiteEncoding);
     readULEB128(&p); // action value not used for C code
     if (landingPad == 0)
       continue; // no landing pad for this entry