https://bugs.kde.org/show_bug.cgi?id=453084
--- Comment #7 from mli...@suse.cz --- > So __memmove_chk is actually an IFUNC that, on first call, resolves to the > optimal implementation for the current preprocessor. > > In this case it chose __memcpy_chk_sse2_unaligned presumably because it > knows that is in fact overlap safe, so as far as valgrind is concerned the > call did in fact wind up going to memcpy and hence got checked. Are you sure about it? If I use gdb, then it's resolved to the following function: Breakpoint 1, __memmove_chk_avx_unaligned () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:206 206 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: Directory not empty. (gdb) bt #0 __memmove_chk_avx_unaligned () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:206 #1 0x000000000040069b in main () at drpm.c:8 which is proved if I put breakpoint to __memmove_chk_ifunc: │ > 0x7ffff7e1ed50 <__memmove_chk_ifunc+290> ret (gdb) p /x $rax $2 = 0x7ffff7e88820 (gdb) p & __memmove_chk_avx_unaligned $3 = (<text variable, no debug info> *) 0x7ffff7e88820 <__memmove_chk_avx_unaligned> -- You are receiving this mail because: You are watching all bug changes.
