This discussion in the ⁠binutils⁠ mailing list is interesting. I had no idea the target binary could easily detect and interact with Valgrind directly. Valgrind provides a header (⁠valgrind.h⁠) to help the client do exactly that. A change in the ⁠gas⁠ assembler that optimized ⁠xchg reg, reg⁠ to ⁠mov reg, reg⁠ in specific conditions broke Valgrind. That optimization yielded more efficient code because the ⁠mov⁠ instruction is cheaper. Valgrind implements a trapdoor—a "hypercall"-like mechanism between the target and Valgrind, officially called the Client Request Mechanism. This trapdoor relies on a magic sequence of preamble instructions followed immediately by an ⁠xchg⁠ instruction. Because the ⁠gas⁠ optimization replaced that ⁠xchg⁠ with a ⁠mov⁠, Valgrind was seeing a ⁠mov⁠ and failing to recognize the request. The problem occurred both when Valgrind itself was built with the optimization, and when target binaries were built with the client-request mechanism through the ⁠valgrind.h⁠ file. ⁠systemd⁠ was one of the affected projects. Because there are many projects out there built with the Valgrind header that hardcode the expectation of an ⁠xchg⁠ instruction, the optimization had to be reverted. That problem resulted in the following error in Valgrind: vex amd64->IR: unhandled instruction bytes: 0x48 0xC1 0xC7 0x3 0x48 0xC1 0xC7 0xD 0x48 0xC1 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=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==568970== valgrind: Unrecognised instruction at address 0x484f1e9. [PATCH 1/2] x86: optimize XCHG to MOV for same-register forms sourceware.org/pipermail/bin… x86: Disable XCHG to MOV optimization sourceware.org/git/?p=binuti… Here is the official documentation of the Client Request Mechanism implemented in Valgrind: valgrind.org/docs/manual/man…