Currently we use RTTI objects to check type compatibility. To support non-unique
RTTI objects, commit 5745eccef54ddd3caca278d1d292a88b2281528b added a
checkTypeInfoEquality string matching to the runtime.
The scheme is inefficient.
_Z1fv: .long 846595819 # jmp .long .L__llvm_rtti_proxy-_Z3funv ... main: ... # Load the second word (pointer to the RTTI object) and dereference it. movslq 4(%rsi), %rax movq (%rax,%rsi), %rdx # Is it the desired typeinfo object? leaq _ZTIFvvE(%rip), %rax # If not, call __ubsan_handle_function_type_mismatch_v1, which may recover if checkTypeInfoEquality allows cmpq %rax, %rdx jne .LBB1_2 ... .section .data.rel.ro,"aw",@progbits .p2align 3, 0x0 .L__llvm_rtti_proxy: .quad _ZTIFvvE
Let's replace the indirect _ZTI pointer with a type hash similar to
-fsanitize=kcfi.
_Z1fv: .long 3238382334 .long 2772461324 # type hash main: ... # Load the second word (callee type hash) and check whether it is expected cmpl $-1522505972, -4(%rax) # If not, fail: call __ubsan_handle_function_type_mismatch jne .LBB2_2
The RTTI object derives its name from clang::MangleContext::mangleCXXRTTI,
which uses mangleType. mangleTypeName uses mangleType as well. So the
type compatibility change is high-fidelity.
Since we no longer need RTTI pointers in
__ubsan::__ubsan_handle_function_type_mismatch_v1, let's switch it back to
version 0, the original signature before
e215996a2932ed7c472f4e94dc4345b30fd0c373 (2019).
__ubsan::__ubsan_handle_function_type_mismatch_abort is not
recoverable, so we can revert some changes from
e215996a2932ed7c472f4e94dc4345b30fd0c373.
Would CalleeTypeHashMatch be a better name?