https://bugs.kde.org/show_bug.cgi?id=374596
--- Comment #14 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
(In reply to bugzilla from comment #13)
> (In reply to Philippe Waroquiers from comment #10)
> There was no cpuid utility available on our host, so we substituted an
> internal 'procinfo' utility that emits similar details; I hope that it gives
> you the information you wanted for that case:
>
> % ./valgrind --trace-flags=10000000 --trace-notbelow=1 --tool=none procinfo
> |& grep -i 'dirty.*cpuid'
> DIRTY 1:I1 MoFX-gst(16,8) WrFX-gst(40,8) MoFX-gst(24,8)
> WrFX-gst(32,8) ::: amd64g_dirtyhelper_CPUID_sse42_and_cx16{0x380eea60}(BBPTR)
So, valgrind pretends to your program to be an sse42/cx16 machine, having
RDTSCP
> 4:24pm mrec-build2.873 ~/bin% ./valgrind --tool=none -v -v -v -d -d -d date
> | & grep 'arch ='
> --28512:1: main ... arch = AMD64, hwcaps = amd64-cx16-sse3
But has not detected RDTSCP on the 'real cpu' hwcaps.
And when it decodes the instruction, it examines the hwcaps, and not what
it has pretended to be to the guest application.
In other words, when your application calls the CPUID instruction,
valgrind executes amd64g_dirtyhelper_CPUID_sse42_and_cx16, which tells RDTSCP
is available.
Then your application (correctly) assumes it can call RDTSCP, but then Valgrind
refuses to
decode it, because the hwcaps it has derived from cpuid call
indicates there is no RDTSCP (which is the case:
your QEMU simulated cpu does not have RDTSCP).
What I still do not understand is that valgrind calls
amd64g_dirtyhelper_CPUID_sse42_and_cx16
only if hwcaps contains SSE3 and CX16.
These 2 flags are reported by by the '.... | grep 'arch =' command.
However, your cat /proc/cpuinfo shows a cx16 flag but does not show an sse3
flag.
So, I am wondering by which miracle m_machine.c has found the sse3 indicator by
calling
cpuid. Maybe there is a bug in QEMU cpuid instruction ?
What is your procinfo procedure giving ?
Does this report the same flags as cat /proc/cpuinfo ?
In particular, does it tell that sse3 is available ?
It would be nice if you could install the cpuid rpm : as far as I can see,
it should be available under centos.
Then we can check the consistency between
cat /proc/cpuinfo (no sse3 found)
valgrind (that seems to find sse3)
your procinfo program : ????
cpuid : ....
If the (wrong) detection of sse3 is really the root cause of wrongly pretending
being RDTSCP,
you might bypass the problem in m_machine.c by assigning False to have_sse3,
rather than deriving it from ecx.
So, in the amd64 section, replace
have_sse3 = (ecx & (1<<0)) != 0; /* True => have sse3 insns */
by
have_sse3 = False;
If this solves the problem, then we can be reasonably sure the decoding is not
the problem,
but is is purely related to cpu model.
If after that patch, we still have a decoding problem, then we might have both
some cpu model problem and/or a basic problem that valgrind decodes an
instruction
that it will not execute.
--
You are receiving this mail because:
You are watching all bug changes.
