https://bugs.kde.org/show_bug.cgi?id=522533
--- Comment #12 from Mark Wielaard <[email protected]> --- (In reply to Mark Wielaard from comment #11) > Created attachment 194238 [details] > x86/x86-64: deal with rewriting assemblers > > Patch by Michael Matz that for x86 and amd64 (only) accepts alternative > special encoding instructions and rewrites valgrind.h to use .byte sequences. So this does more than just warn when a "bad" instruction is detected. For the warning I pushed my proposed patch since that covers all architectures. commit 41d8cf1370d66b328a63c65891c2de450f19b00b Author: Mark Wielaard <[email protected]> Date: Sun Jul 5 22:12:02 2026 +0200 VEX: warn when special instr preamble is followed by unknown instruction When someone compiles a program (or the valgrind preload library) with -Wa,-O2 then binutils gas might "optimize" the special instructions in valgrind.h away (since they are essentially NOPs). When that happens they'll get a somewhat incomprehensible error message. Explicitly print what is happening (if we are doing sigill diagnostics, which defaults to yes): special instruction preamble followed by unknown instruction this can happen when inline valgrind.h assembly is optimized (away) https://bugs.kde.org/show_bug.cgi?id=522533 (Note that the "normal" sigill handler" already prints the bad instruction bytes, which is why they aren't also printed in the new warning.) So that leaves us with a) recognizing some mov instructions instead of the expected xchg instructions because that is what the currently development gas does when called with -O1 or -O2. And b) changing the x86 and amd64 sections of valgrind.h to use .byte sequences instead of x86 assembly instructions. For a) I am wondering if this is premature because this is currently only in a non-released development version of gas. It might still be reverted or further "optimized" by just removing the whole same register xchg or mov because those are seen as nops. For b) it should at least have comments what the real assembly looks like, the .byte sequence on its own is kind of unreadable. If we want to encode our inline assembly this way shouldn't we also do it for the other architectures (arm64, arm, mips, ppc, riscv64 and s390)? -- You are receiving this mail because: You are watching all bug changes.
