[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
GitOrigin-RevId: 5748a71ba3da69e9f0bfb2024eadfe6eeacade01
diff --git a/lib/builtins/gcc_personality_v0.c b/lib/builtins/gcc_personality_v0.c
index d12ee03..9fb1ce0 100644
--- a/lib/builtins/gcc_personality_v0.c
+++ b/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 @@
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
