Starting with Arm v8.8/v9.3, a new architectural feature (FEAT_MOPS) provides new instructions to perform memory copy and memory set operations in a standardized way. There are specialized versions of memcpy, memmove and memset using them in glibc 2.39. These instructions appear as a sequence of 3: one prologue, one main and one epilogue instruction. The AArch64 target of GDB needs two things to support them: 1. Recognize the trio of instructions as one atomic sequence. 2. Recognize the instructions for record/replay. Patches for both are being finalized and will be posted in the next few days.
Hello, Posted the patch series here: https://inbox.sourceware.org/gdb-patches/20240504000521.314531-1-thiago.bauermann@linaro.org/
Posted v2: https://inbox.sourceware.org/gdb-patches/20240507022249.554831-1-thiago.bauermann@linaro.org/
The master branch has been updated by Thiago Bauermann <bauermann@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b995344c116e04bd6bfeaf53364cd791d0dae45d commit b995344c116e04bd6bfeaf53364cd791d0dae45d Author: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Date: Sat Apr 27 18:38:22 2024 -0300 gdb/aarch64: Disable displaced single-step for MOPS instructions The AArch64 MOPS (Memory Operation) instructions provide a standardised instruction sequence to perform a memset, memcpy or memmove. A sequence is always composed of three instructions: a prologue instruction, a main instruction and an epilogue instruction. As an illustration, here are the implementations of these memory operations in glibc 2.39: (gdb) disassemble/r Dump of assembler code for function __memset_mops: => 0x0000fffff7e8d780 <+0>: d503201f nop 0x0000fffff7e8d784 <+4>: aa0003e3 mov x3, x0 0x0000fffff7e8d788 <+8>: 19c10443 setp [x3]!, x2!, x1 0x0000fffff7e8d78c <+12>: 19c14443 setm [x3]!, x2!, x1 0x0000fffff7e8d790 <+16>: 19c18443 sete [x3]!, x2!, x1 0x0000fffff7e8d794 <+20>: d65f03c0 ret End of assembler dump. (gdb) disassemble/r Dump of assembler code for function __memcpy_mops: => 0x0000fffff7e8c580 <+0>: d503201f nop 0x0000fffff7e8c584 <+4>: aa0003e3 mov x3, x0 0x0000fffff7e8c588 <+8>: 19010443 cpyfp [x3]!, [x1]!, x2! 0x0000fffff7e8c58c <+12>: 19410443 cpyfm [x3]!, [x1]!, x2! 0x0000fffff7e8c590 <+16>: 19810443 cpyfe [x3]!, [x1]!, x2! 0x0000fffff7e8c594 <+20>: d65f03c0 ret End of assembler dump. (gdb) disassemble/r Dump of assembler code for function __memmove_mops: => 0x0000fffff7e8d180 <+0>: d503201f nop 0x0000fffff7e8d184 <+4>: aa0003e3 mov x3, x0 0x0000fffff7e8d188 <+8>: 1d010443 cpyp [x3]!, [x1]!, x2! 0x0000fffff7e8d18c <+12>: 1d410443 cpym [x3]!, [x1]!, x2! 0x0000fffff7e8d190 <+16>: 1d810443 cpye [x3]!, [x1]!, x2! 0x0000fffff7e8d194 <+20>: d65f03c0 ret End of assembler dump. The Arm Architecture Reference Manual says that "the prologue, main, and epilogue instructions are expected to be run in succession and to appear consecutively in memory". Therefore this patch disables displaced stepping on them. The testcase verifies that MOPS sequences are correctly single-stepped. PR tdep/31666 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666 Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>
The master branch has been updated by Thiago Bauermann <bauermann@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ebd06ca6b9bb2327e1269b52eb99b2f012faabf9 commit ebd06ca6b9bb2327e1269b52eb99b2f012faabf9 Author: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Date: Sat Apr 20 23:18:26 2024 -0300 gdb/aarch64: Add record support for MOPS instructions. There are two kinds of MOPS instructions: set instructions and copy instructions. Within each group there are variants with minor differences in how they read or write to memory â e.g., non-temporal read and/or write, unprivileged read and/or write and permutations of those â but they work in the same way in terms of the registers and regions of memory that they modify. The new gdb.reverse/aarch64-mops.exp testcase verifies that MOPS instructions are recorded and correctly reversed. Not all variants of the copy and set instructions are tested, since there are many and the record and replay target processes them in the same way. PR tdep/31666 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666 Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>
The gdb-15-branch branch has been updated by Thiago Bauermann <bauermann@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8215789c478d3fc006a94d4e7c1273329aa8c773 commit 8215789c478d3fc006a94d4e7c1273329aa8c773 Author: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Date: Sat Apr 27 18:38:22 2024 -0300 gdb/aarch64: Disable displaced single-step for MOPS instructions The AArch64 MOPS (Memory Operation) instructions provide a standardised instruction sequence to perform a memset, memcpy or memmove. A sequence is always composed of three instructions: a prologue instruction, a main instruction and an epilogue instruction. As an illustration, here are the implementations of these memory operations in glibc 2.39: (gdb) disassemble/r Dump of assembler code for function __memset_mops: => 0x0000fffff7e8d780 <+0>: d503201f nop 0x0000fffff7e8d784 <+4>: aa0003e3 mov x3, x0 0x0000fffff7e8d788 <+8>: 19c10443 setp [x3]!, x2!, x1 0x0000fffff7e8d78c <+12>: 19c14443 setm [x3]!, x2!, x1 0x0000fffff7e8d790 <+16>: 19c18443 sete [x3]!, x2!, x1 0x0000fffff7e8d794 <+20>: d65f03c0 ret End of assembler dump. (gdb) disassemble/r Dump of assembler code for function __memcpy_mops: => 0x0000fffff7e8c580 <+0>: d503201f nop 0x0000fffff7e8c584 <+4>: aa0003e3 mov x3, x0 0x0000fffff7e8c588 <+8>: 19010443 cpyfp [x3]!, [x1]!, x2! 0x0000fffff7e8c58c <+12>: 19410443 cpyfm [x3]!, [x1]!, x2! 0x0000fffff7e8c590 <+16>: 19810443 cpyfe [x3]!, [x1]!, x2! 0x0000fffff7e8c594 <+20>: d65f03c0 ret End of assembler dump. (gdb) disassemble/r Dump of assembler code for function __memmove_mops: => 0x0000fffff7e8d180 <+0>: d503201f nop 0x0000fffff7e8d184 <+4>: aa0003e3 mov x3, x0 0x0000fffff7e8d188 <+8>: 1d010443 cpyp [x3]!, [x1]!, x2! 0x0000fffff7e8d18c <+12>: 1d410443 cpym [x3]!, [x1]!, x2! 0x0000fffff7e8d190 <+16>: 1d810443 cpye [x3]!, [x1]!, x2! 0x0000fffff7e8d194 <+20>: d65f03c0 ret End of assembler dump. The Arm Architecture Reference Manual says that "the prologue, main, and epilogue instructions are expected to be run in succession and to appear consecutively in memory". Therefore this patch disables displaced stepping on them. The testcase verifies that MOPS sequences are correctly single-stepped. PR tdep/31666 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666 Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com> (cherry picked from commit b995344c116e04bd6bfeaf53364cd791d0dae45d)
The gdb-15-branch branch has been updated by Thiago Bauermann <bauermann@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8fb41483be64f5e606c0e8e22652960535406cb4 commit 8fb41483be64f5e606c0e8e22652960535406cb4 Author: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Date: Sat Apr 20 23:18:26 2024 -0300 gdb/aarch64: Add record support for MOPS instructions. There are two kinds of MOPS instructions: set instructions and copy instructions. Within each group there are variants with minor differences in how they read or write to memory â e.g., non-temporal read and/or write, unprivileged read and/or write and permutations of those â but they work in the same way in terms of the registers and regions of memory that they modify. The new gdb.reverse/aarch64-mops.exp testcase verifies that MOPS instructions are recorded and correctly reversed. Not all variants of the copy and set instructions are tested, since there are many and the record and replay target processes them in the same way. PR tdep/31666 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666 Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com> (cherry picked from commit ebd06ca6b9bb2327e1269b52eb99b2f012faabf9)
I suppose this is done now?
It is. I hadn't realised I was able to close tickets in this bugzilla.
Closing.