libarmmem symbol issues prevent Valgrind redirs

[Pjfloyd]

Valgrind should redirect the functions in libarmmem, mainly to check for overlaps but also partly to avoid false positives due to SIMD optimizations reading beyond the terminating nul (Valgrind has a second mechanism to avoid such false positives, but that doesn't work in this case).

It would also help if the shared library contained its soname.

See https://bugs.kde.org/show_bug.cgi?id=398569 for more details.

To check, run

./vg-in-place --trace-symtab=yes --log-file=sym.log memcheck/tests/memccpy2

(vg-in-place is for running Valgrind in its own source directory, any executable should do for the test).

Look for the libarmmem section starting with

------ start ELF OBJECT -------------------------------------------------------
------ name = /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so

The key part is this table

--- Reading (ELF, standard) dynamic symbol table (14 entries) ---
raw symbol [ 1]: LOC SEC : svma 0x0000000374, sz 0 NONAME
raw symbol [ 2]: LOC SEC : svma 0x0000014024, sz 0 NONAME
raw symbol [ 3]: WEA FUN : svma 0x0000000000, sz 0 __cxa_finalize
    ignore -- size=0: __cxa_finalize
raw symbol [ 4]: WEA NOT : svma 0x0000000000, sz 0 _ITM_deregisterTMCloneTable
raw symbol [ 5]: WEA NOT : svma 0x0000000000, sz 0 __gmon_start__
raw symbol [ 6]: WEA NOT : svma 0x0000000000, sz 0 _ITM_registerTMCloneTable
raw symbol [ 7]: GLO NOT : svma 0x00000030f8, sz 0 memset
raw symbol [ 8]: GLO NOT : svma 0x00000030e4, sz 0 mempcpy
raw symbol [ 9]: GLO NOT : svma 0x00000031c0, sz 0 strlen
raw symbol [ 10]: GLO NOT : svma 0x000000216c, sz 0 memmove
raw symbol [ 11]: GLO NOT : svma 0x00000030e4, sz 0 __mempcpy
raw symbol [ 12]: GLO NOT : svma 0x0000000b58, sz 0 memcpy
raw symbol [ 13]: GLO NOT : svma 0x00000004d0, sz 0 memcmp

"GLO NOT" means "global notype". Valgrind will ignore notype objects. "sz 0" is also a problem as Valgrind will ignore objects with a size of 0.

Valgrind also needs some modifications, but that requires libarmmem to be fixed first.

[Pjfloyd (pjfloyd)]

Initial version.

I'm not sure what should be done with __mempcpy. Is that an alias that should also by type FUNC and have a size?

With this I get

paulf@raspberrypi:~/scratch/arm-mem $ readelf -s libarmmem-v7l.so | grep FUNC | grep GLOB
     7: 00003094 20 FUNC GLOBAL DEFAULT 9 mempcpy
     8: 000030a8 200 FUNC GLOBAL DEFAULT 9 memset
     9: 00003170 320 FUNC GLOBAL DEFAULT 9 strlen
    10: 0000211c 3960 FUNC GLOBAL DEFAULT 9 memmove
    12: 00000b08 5652 FUNC GLOBAL DEFAULT 9 memcpy
    13: 00000480 1672 FUNC GLOBAL DEFAULT 9 memcmp
    88: 0000211c 3960 FUNC GLOBAL DEFAULT 9 memmove
    89: 00000b08 5652 FUNC GLOBAL DEFAULT 9 memcpy
    91: 00003094 20 FUNC GLOBAL DEFAULT 9 mempcpy
    93: 00000480 1672 FUNC GLOBAL DEFAULT 9 memcmp
    95: 000030a8 200 FUNC GLOBAL DEFAULT 9 memset
    97: 00003170 320 FUNC GLOBAL DEFAULT 9 strlen

which is certainly better.

[peter green (plugwash)]

To clarify, is this a patch against valgrind (and if so what version of valgrind) or is it a patch against libarmmem?

[Pjfloyd (pjfloyd)]

For libarmmem.

I will push the corresponding changes for Valgrind when this gets fixed.

[Pjfloyd (pjfloyd)]

On the Valgrind side, see

https://bugs.kde.org/show_bug.cgi?id=398569

I'll probably provide a patch there as well, which will be for Valgrind git HEAD.

[Pjfloyd (pjfloyd)]

I've added the soname build option to the Makefile and also added type and size for __mempcpy

[Pjfloyd (pjfloyd)]

I opened a git pull request upstream which was accepted and merged

https://github.com/bavison/arm-mem/pull/12