https://bugs.kde.org/show_bug.cgi?id=449672
Bug ID: 449672
Summary: ppc64 --track-origins=yes causes failures because of
bad cmov addHRegUse
Product: valgrind
Version: 3.18.1
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: vex
Assignee: jsew...@acm.org
Reporter: m...@klomp.org
CC: c...@us.ibm.com, will_schm...@vnet.ibm.com
Target Milestone: ---
We had an issue with some code running under memcheck with --track-origins=yes
which caused a crash, it ran fine without any issues under memcheck without
--track-origins=yes.
Unfortunately the issue was a nontrivial test for an security issue (which I
cannot disclose as is) and it only happens deep inside glibc and only when
glibc is build with GCC 11.2.1.
Julian suggested to look at the Pin_CMov reg usage and we found this:
diff --git a/VEX/priv/host_ppc_defs.c b/VEX/priv/host_ppc_defs.c
index 3ae0f6e08..4222b4786 100644
--- a/VEX/priv/host_ppc_defs.c
+++ b/VEX/priv/host_ppc_defs.c
@@ -2590,7 +2590,7 @@ void getRegUsage_PPCInstr ( HRegUsage* u, const PPCInstr*
i, Bool mode64 )
return;
case Pin_CMov:
addRegUsage_PPCRI(u, i->Pin.CMov.src);
- addHRegUse(u, HRmWrite, i->Pin.CMov.dst);
+ addHRegUse(u, HRmModify, i->Pin.CMov.dst);
return;
case Pin_Load:
addRegUsage_PPCAMode(u, i->Pin.Load.src);
And that resolved it.
Since this is a conditional move the register could be both read and written
(read + write = modify). This matches the dst of Pin_FpCMov and Pin_AvCMov.
This is slightly amazing, this code is from 2005 and as far as I know we never
seen an issue with --track-origins=yes on power before. And I have been unable
to come up with a simpler reproducer.
--
You are receiving this mail because:
You are watching all bug changes.
