The problem is with the valgrind tests.  The specfile appears to set a BuildRequires for valgrind on armv7hl so I don't believe the issue is a missing valgrind binary, this means it is likely a valgrind notice/error.

Considering we aren't seeing valgrind notifications on any other arch/ABI, and that every single libseccomp valgrind test is failing, I suspect there is some issue with valgrind or the armv7hl toolchain.

I've requested a armv7hl system from Stephen (reporter) to try and get further information.

I'm moving this to glibc. I can verify that valgrind is failing on all armv7hl runs, apparently in ld-2.25.so:

==9495== Memcheck, a memory error detector
==9495== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9495== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==9495== Command: ./success
==9495== 
==9495== Conditional jump or move depends on uninitialised value(s)
==9495==    at 0x401CF84: index (in /usr/lib/ld-2.25.so)
==9495== 
==9495== Conditional jump or move depends on uninitialised value(s)
==9495==    at 0x401CF88: index (in /usr/lib/ld-2.25.so)
==9495== 
==9495== 
==9495== HEAP SUMMARY:
==9495==     in use at exit: 0 bytes in 0 blocks
==9495==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==9495== 
==9495== All heap blocks were freed -- no leaks are possible
==9495== 
==9495== For counts of detected and suppressed errors, rerun with: -v
==9495== Use --track-origins=yes to see where uninitialised values come from
==9495== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 2 from 1)


I can reproduce this with any executable on armv7hl; I tested it with the following program (compiled with gcc-7.1.1-3.fc26.armv7hl):

```
int main(int argc, char **argv)
{
    return 0;
}
```

For the record, I used arm03-packager01.cloud.fedoraproject.org which should be available to anyone with a Fedora account in the 'packager' group. I installed Fedora 26 pre-release with the latest updates as of this writing. Feel free to use this system to verify the issue.

(In reply to Stephen Gallagher from comment #2)
> ==9495== Conditional jump or move depends on uninitialised value(s)
> ==9495==    at 0x401CF84: index (in /usr/lib/ld-2.25.so)
> ==9495== 
> ==9495== Conditional jump or move depends on uninitialised value(s)
> ==9495==    at 0x401CF88: index (in /usr/lib/ld-2.25.so)

Would you please try again after installing glibc debugging information?  Thanks.

Never mind, I see that debugging information is already installed, but valgrind does not appear to use it.

The cause was an outdated glibc-debuginfo package.  The valgrind suppression file apparently needs debugging information on armhfp to perform proper suppressions.

Disabling them again shows what's going on:

==32711== Conditional jump or move depends on uninitialised value(s)
==32711==    at 0x401CF84: index (strchr.S:99)
==32711==    by 0x4009563: expand_dynamic_string_token (dl-load.c:371)
==32711==    by 0x4009563: _dl_map_object (dl-load.c:2146)
==32711==    by 0x4000DEB: map_doit (rtld.c:586)
==32711==    by 0x401B633: _dl_catch_error (dl-error-skeleton.c:198)
==32711==    by 0x4001F7B: do_preload (rtld.c:757)
==32711==    by 0x4001F7B: handle_ld_preload (rtld.c:855)
==32711==    by 0x400403F: dl_main (rtld.c:1609)
==32711==    by 0x401A497: _dl_sysdep_start (dl-sysdep.c:253)
==32711==    by 0x4001883: _dl_start_final (rtld.c:410)
==32711==    by 0x4001883: _dl_start (rtld.c:516)
==32711==    by 0x4000ACF: ??? (in /usr/lib/ld-2.25.so)
==32711==  Uninitialised value was created by a stack allocation
==32711==    at 0x4001EB8: handle_ld_preload (rtld.c:832)

index/strchr is doing a word load from a partially-written stack-allocated buffer, therefore accessing uninitialized data.  This is normal for an optimized string function.  The uninitialized data does not affect the function result.

Please don't close this; if the specific issue I raised is wrong, something is still causing valgrind to fail when building libseccomp on armv7hl.

I'll move back to that component for the moment while I investigate.

Lets assume this is a valgrind bug. It might be a glibc issue too though (looks like the ld.so symbol table is missing on arm?). Will investigate.

Reassigning to valgrind at Mark Wielaard's request.

For ld.so we need a "hardwire" to intercept string/mem functions. We don't have one for index on arm32. We do for almost every other architecture. That is probably why this only shows up on arm32.

This was probably introduced by one of the recent security fixes in glibc.

commit 6d0ba622891bed9d8394eef1935add53003b12e8
Author: Florian Weimer <fweimer>
Date:   Mon Jun 19 22:31:04 2017 +0200

    ld.so: Reject overly long LD_PRELOAD path elements

valgrind uses LD_PRELOAD to load memcheck. So this path is most likely triggered.

I'll add a index/strchr hardwire for arm32 to see if that resolves the issue.

Created attachment 1292902 [details]
ARM hardwire for ld.so index function

The attached valgrind patch seems to solve the issue. There already was some code for an arm32 ld.so index function replacement it just wasn't hardwired yet.

valgrind-3.13.0-4.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4315a2f0cd

valgrind-3.13.0-4.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4315a2f0cd

valgrind-3.12.0-9.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ffd8b851cc

valgrind-3.11.0-27.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-1320773bc5

valgrind-3.12.0-9.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ffd8b851cc

valgrind-3.11.0-27.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-1320773bc5

valgrind-3.13.0-4.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

valgrind-3.12.0-9.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

valgrind-3.11.0-27.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.