samitolvanen wrote:
Unfortunately, the `__kcfi_typeid_` values are intentionally zero-extended, so
they can be used in relocations with `movl`. With your patch applied:
```
...
LD .tmp_vmlinux1
ld.lld: error: vmlinux.o:(function __cfi___memcpy: .noinstr.text+0x4ac1):
relocation R_X86_64_32 out of range: 18446744071952041092 is not in [0,
4294967295]; references '__kcfi_typeid___memcpy'
>>> referenced by usercopy_64.c
>>> defined in vmlinux.o
...
$ llvm-objdump -d -r arch/x86/lib/memcpy_64.o
...
0000000000000010 <__cfi___memcpy>:
10: b8 00 00 00 00 movl $0x0, %eax
0000000000000011: R_X86_64_32 __kcfi_typeid___memcpy
...
$ llvm-readelf --symbols vmlinux.o | grep __kcfi_typeid___memcpy
214399: ffffffff973e8484 0 NOTYPE WEAK DEFAULT ABS
__kcfi_typeid___memcpy
```
See the `__CFI_TYPE` definition here:
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/include/asm/linkage.h#n100
In hindsight, adding a test to LLVM about this real-world `__kcfi_typeid_` use
case would probably be a good idea.
https://github.com/llvm/llvm-project/pull/136734
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
