Under the ARM EHABI, type information is encoded as a TARGET2 value,
rather than a DWARF pointer.

For the kernel ELF object, we have a ttype_encoding of DW_EH_PE_absptr,
which we combine with DW_EH_PE_pcrel when reading the type info.

For non-null pointers, this is equivalent to TARGET2 - we read a 32bit
value, and then use it as an offset from the current DWARF info. However,
null pointers should *not* apply an offset, and should instead return 0
directly.

An alternative fix here would be to change read_encoded_pointer_with_base
to skip adding base/original_ptr when reading 0. This is what GCC
does[^1], but feels a more dangerous change.

[^1]: 2a77afa0ee/libgcc/unwind-pe.h (L265)

@@ -75,17 +75,23 @@ unsafe fn get_ttype_entry(
     ttype_base: usize,
     ttype: *const u8,
 ) -> Result<Option<*const u8>, ()> {
+    if encoding != DW_EH_PE_absptr {

@@ -89,0 +84,4 @@
+    // Read in a target2 value. See "Personality routine exception-handling table
+    // entries" in the ehabi32 spec, and the ARM_EHABI version of `get_shim_type_info`
+    // in LLVM's libcxxabi/src/cxa_personality.cpp.
+    let mut reader = DwarfReader::new(ttype.offset(-i));