[valgrind] [Bug 369459] New: valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
https://bugs.kde.org/show_bug.cgi?id=369459 Bug ID: 369459 Summary: valgrind on arm64 violates the ARMv8 spec (ldxr/stxr) Product: valgrind Version: 3.12 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: critical Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: pins...@gcc.gnu.org So on ARMv8, valgrind invokes undefined behavior with respect to ldxr/stxr. This causes valgrind to hang on ThunderX machines. here is the disassembly when I attach gdb to the valgrind process: 0x0008034001a4: ldxrw2, [x4] 0x0008034001a8: mov x22, x2 0x0008034001ac: and x24, x23, #0x 0x0008034001b0: and x23, x22, #0x 0x0008034001b4: str x24, [x21,#928] 0x0008034001b8: str x23, [x21,#32] 0x0008034001bc: dsb sy => 0x0008034001c0: dmb sy 0x0008034001c4: isb …. 0x0008034000e4: stxrw0, w2, [x4] As you can see there are plenty of stores and even DSB/DMB/ISB inbetween the ldxr and stxr. All of this violates the ARM spec and says stxr can always fail and it does on ThunderX. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
https://bugs.kde.org/show_bug.cgi?id=369459 --- Comment #1 from Andrew Pinski --- This is very much related to https://bugs.kde.org/show_bug.cgi?id=344524 (which is recorded for MIPS and it just happens both are Cavium cores too). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
https://bugs.kde.org/show_bug.cgi?id=369459 --- Comment #4 from Andrew Pinski --- (In reply to Julian Seward from comment #3) > Andrew, do you know which implementation this is? eg is it a Cortex > A-something, > or something else? It is a custom ARMv8-a core produced by Cavium. It is not a cortex-a based at all. We had a similar issues with Oracle JDK but we worked with Oracle to fix it; that was a year or so ago. As mentioned we have a similar issue with the MIPS64 implementation of valgrind with our (Cavium's) MIPS64r3 core (Octeon 3). I suspect this is going to need a fundamental change in valgrind to fix both of these issues. One idea I have is to pattern match on the ldxr/stxr sequence and produce a single instruction in the IR -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
https://bugs.kde.org/show_bug.cgi?id=369459 --- Comment #5 from Andrew Pinski --- Opps pressed save too soon. One idea I have is to pattern match on the ldxr/stxr sequence and produce a single instruction in the IR and then decode them after the fact. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369509] New: ARMv8.1 LSE instructions are not supported
https://bugs.kde.org/show_bug.cgi?id=369509 Bug ID: 369509 Summary: ARMv8.1 LSE instructions are not supported Product: valgrind Version: 3.12 SVN Platform: Other OS: other Status: UNCONFIRMED Severity: grave Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: pins...@gcc.gnu.org Looking into the code I noticed that the ARMv8.1 LSE instructions are not supported so any code compiled with -mcpu=thunderx+lse crashes (well we ran into 369459 first but that is a different story). Reproducible: Always Steps to Reproduce: Compile glibc with -mcpu=thunderx+lse and run any resulting binary with this ld.so. We get a crash with unknown instructions -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369509] ARMv8.1-a LSE instructions are not supported
https://bugs.kde.org/show_bug.cgi?id=369509 Andrew Pinski changed: What|Removed |Added Summary|ARMv8.1 LSE instructions|ARMv8.1-a LSE instructions |are not supported |are not supported -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
https://bugs.kde.org/show_bug.cgi?id=369459
--- Comment #10 from Andrew Pinski ---
>Andrew, is there a way to automatically detect the relevant cores at
startup time
You could scan /proc/cpuinfo for the "CPU implementer" value of 0x43 ('C') but
that only catches the current cores which have this micro-arch effect. Someone
else in the future could implement this same issue too since they are following
the arch to letter.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
https://bugs.kde.org/show_bug.cgi?id=369459 --- Comment #13 from Andrew Pinski --- (In reply to Julian Seward from comment #12) > Andrew, do you know how well Maran's proposal > https://bugs.kde.org/show_bug.cgi?id=344524#c8 worked on MIPS64r3 (Octeon 3) > ? > IOW is it worth taking and generalising? We did not test it too much, in that we tested it only for a few weeks and was going to let imagination take over to see if it worked more and fix it for MIPS but they never did. -- You are receiving this mail because: You are watching all bug changes.
