https://bugzilla.redhat.com/show_bug.cgi?id=1906980 Ben Beasley <code@xxxxxxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|nobody@xxxxxxxxxxxxxxxxx |code@xxxxxxxxxxxxxxxxxx Flags| |needinfo?(zebob.m@xxxxxxxxx | |) --- Comment #15 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- Looks like it’s the benchmarking/timer code, which gets called even with --gtest_list_tests: > [reviewer@musicbox x86_64-redhat-linux-gnu]$ valgrind ./tests/hwy_test --gtest_list_tests > ==147381== Memcheck, a memory error detector > ==147381== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==147381== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info > ==147381== Command: ./tests/hwy_test --gtest_list_tests > ==147381== > vex amd64->IR: unhandled instruction bytes: 0xF 0x1 0xF9 0xF 0xAE 0xE8 0x29 0xF8 0x48 0x83 > vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 > vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F > vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 > ==147381== valgrind: Unrecognised instruction at address 0x10eb5a. > ==147381== at 0x10EB5A: Stop32 (nanobenchmark.cc:310) > ==147381== by 0x10EB5A: hwy::(anonymous namespace)::TimerResolution() (nanobenchmark.cc:457) > ==147381== by 0x10EBEC: __static_initialization_and_destruction_0 (nanobenchmark.cc:465) > ==147381== by 0x10EBEC: _GLOBAL__sub_I_nanobenchmark.cc (nanobenchmark.cc:721) > ==147381== by 0x1865BC: __libc_csu_init (in /home/reviewer/rpmbuild/BUILD/highway-0.11.1/x86_64-redhat-linux-gnu/tests/hwy_test) > ==147381== by 0x4C6616D: (below main) (in /usr/lib64/libc-2.32.so) > ==147381== Your program just tried to execute an instruction that Valgrind > ==147381== did not recognise. There are two possible reasons for this. > ==147381== 1. Your program has a bug and erroneously jumped to a non-code > ==147381== location. If you are running Memcheck and you just saw a > ==147381== warning about a bad jump, it's probably your program's fault. > ==147381== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==147381== i.e. it's Valgrind's fault. If you think this is the case or > ==147381== you are not sure, please let us know and we'll try to fix it. > ==147381== Either way, Valgrind will now raise a SIGILL signal which will > ==147381== probably kill your program. > ==147381== > ==147381== Process terminating with default action of signal 4 (SIGILL): dumping core > ==147381== Illegal opcode at address 0x10EB5A > ==147381== at 0x10EB5A: Stop32 (nanobenchmark.cc:310) > ==147381== by 0x10EB5A: hwy::(anonymous namespace)::TimerResolution() (nanobenchmark.cc:457) > ==147381== by 0x10EBEC: __static_initialization_and_destruction_0 (nanobenchmark.cc:465) > ==147381== by 0x10EBEC: _GLOBAL__sub_I_nanobenchmark.cc (nanobenchmark.cc:721) > ==147381== by 0x1865BC: __libc_csu_init (in /home/reviewer/rpmbuild/BUILD/highway-0.11.1/x86_64-redhat-linux-gnu/tests/hwy_test) > ==147381== by 0x4C6616D: (below main) (in /usr/lib64/libc-2.32.so) > ==147381== > ==147381== HEAP SUMMARY: > […] So it’s actually the RDTSCP instruction that’s the issue here, not any of the SIMD in the library. I don’t love adjusting the build settings based on the build host, but this is a %build section that works on my machine: > %ifarch x86_64 %{ix86} > # Even listing tests invokes the “nanobenchmark” code; on x86, this uses > # RDTSCP, which may not be available, and the build process runs the test > # executables to list the tests. We must therefore skip building the tests on > # hosts without RDTSCP.” > if ! grep -E '\brdtscp\b' /proc/cpuinfo >/dev/null > then > build_testing='OFF' > fi > %endif > %cmake -DHWY_SYSTEM_GTEST:BOOL=ON -DBUILD_TESTING:BOOL="${build_testing-ON}" > %cmake_build On the other hand, while it is difficult to find documentation on exactly which CPU models have supported RDTSCP, I think 64-bit CPUs without it are rather rare. This is mine: https://ark.intel.com/content/www/us/en/ark/products/29765/intel-core-2-quad-processor-q6600-8m-cache-2-40-ghz-1066-mhz-fsb.html. So it really may not be worth working around this case. ----- If you post the spec and SRPM as you want them reviewed, I am prepared to do the review by: 1. Running fedora-review on a copy where I have disabled building the tests. 2. Doing a Koji scratch-build with your unmodified submission, then doing rpmlint and some manual queries on the resulting RPMs. I won’t ask for a workaround for the build-time RDTSCP requirement, as the one I posted above has disadvantages and, considering which particular instruction is the issue, it’s unlikely to be a problem on Koji or on any but a very select few workstations. I expect I will be able to approve this without any further quibbles. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
