https://bugs.kde.org/show_bug.cgi?id=453084
Siddhesh Poyarekar <siddh...@gotplt.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |siddh...@gotplt.org
--- Comment #9 from Siddhesh Poyarekar <siddh...@gotplt.org> ---
(In reply to Tom Hughes from comment #6)
> 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.
The problem is that __memcpy_chk_sse2_unaligned and
__memmove_chk_sse2_unaligned are aliases to the same function:
```
$ nm /lib64/libc.so.6 | grep "__mem\(cpy\|move\)_chk_sse2_unaligned$"
00000000000b9c50 t __memcpy_chk_sse2_unaligned
00000000000b9c50 t __memmove_chk_sse2_unaligned
```
Maybe valgrind could see if the function has a *memmove* alias before it
triggers the warning?
(In reply to mliska from comment #7)
> 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.
Again, the memcpy and memmove variants are aliases and one just happened to be
selected over another, or maybe gdb has some smarts to make it happen, I don't
know:
```
$ nm /lib64/libc.so.6 | grep "__mem\(cpy\|move\)_chk_avx_unaligned$"
00000000001828a0 t __memcpy_chk_avx_unaligned
00000000001828a0 t __memmove_chk_avx_unaligned
```
--
You are receiving this mail because:
You are watching all bug changes.
