https://bugzilla.redhat.com/show_bug.cgi?id=1906980
Ben Beasley <code(a)musicinmybrain.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|nobody(a)fedoraproject.org |code(a)musicinmybrain.net
Flags| |needinfo?(zebob.m(a)gmail.com
| |)
--- Comment #15 from Ben Beasley <code(a)musicinmybrain.net> ---
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-q....
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