)]}'
{
  "commit": "5ea1eec52f47fbc9155bd8f057d26429e6881628",
  "tree": "3e6ba270f189f1cddf8c797a4b06b930aa72024a",
  "parents": [
    "faaee6b411411f3c1f45768d7ac15559fd27b980"
  ],
  "author": {
    "name": "Tom de Vries",
    "email": "tdevries@suse.de",
    "time": "Wed Apr 09 08:59:42 2025 +0200"
  },
  "committer": {
    "name": "Tom de Vries",
    "email": "tdevries@suse.de",
    "time": "Wed Apr 09 08:59:42 2025 +0200"
  },
  "message": "[gdb/tdep] Handle ldaex and stlex in {thumb,arm}_deal_with_atomic_sequence_raw\n\nThe Linaro CI reported a regression [1] in test-case\ngdb.base/step-over-syscall.exp due to commit 674d4856730 (\"[gdb/testsuite] Fix\ngdb.base/step-over-syscall.exp with glibc 2.41\").\n\nInvestigation shows that it\u0027s a progression in the sense that the test-case\nfails at a later point than before.\n\nThe cause for the test-case failure is that an atomic sequence\nldaex/adds/strex is not skipped over when instruction stepping, leading to a\nhang (in the sense of not being able to instruction-step out of the loop\ncontaining the atomic sequence).\n\nThe arm target does have support for recognizing atomic sequences, but it\nfails because it doesn\u0027t recognize the ldaex insn.\n\nFix this by:\n- adding a new function ldaex_p which recognizes ldaex instructions, based\n  on information found in opcodes/arm-dis.c, and\n- using ldaex_p in thumb_deal_with_atomic_sequence_raw.\n\nI was not able to reproduce the failure in its original setting, but I\nwas able to do so using a test.c:\n...\nstatic void exit (int status) {\n  while (1)\n    ;\n}\nvoid _start (void) {\n  int a \u003d 0;\n  __atomic_fetch_add (\u0026a, 1, __ATOMIC_ACQUIRE);\n  exit (0);\n}\n...\ncompiled like this:\n...\n$ gcc test.c -march\u003darmv8-a -mfloat-abi\u003dsoft -nostdlib -static\n...\ngiving this atomic sequence of 32-bit Thumb-2 instructions:\n...\n   100ce:       e8d3 1fef       ldaex   r1, [r3]\n   100d2:       f101 0101       add.w   r1, r1, #1\n   100d6:       e843 1200       strex   r2, r1, [r3]\n...\n\nWithout the fix, after 100 stepi\u0027s we\u0027re still in _start (and likewise with\n10.000 stepi\u0027s):\n...\n$ gdb -q -batch a.out -ex \u0027display /i $pc\u0027 -ex starti -ex \"stepi 100\"\n  ...\n0x000100dc in _start ()\n1: x/i $pc\n\u003d\u003e 0x100dc \u003c_start+26\u003e:\tbne.n\t0x100ce \u003c_start+12\u003e\n...\nbut with the fix we\u0027ve managed to progress to exit:\n...\n$ gdb -q -batch a.out -ex \u0027display /i $pc\u0027 -ex starti -ex \"stepi 100\"\n  ...\n0x000100c0 in exit ()\n1: x/i $pc\n\u003d\u003e 0x100c0 \u003cexit+8\u003e:\tb.n\t0x100c0 \u003cexit+8\u003e\n...\n\nHaving addressed the \"-mthumb\" case, do we need a similar fix for \"-marm\"?\n\nAdding \"-marm\" in the compilation line mentioned above gives the following\natomic sequence:\n...\n   100e4:       e1931e9f        ldaex   r1, [r3]\n   100e8:       e2811001        add     r1, r1, #1\n   100ec:       e1832f91        strex   r2, r1, [r3]\n...\nand gdb already recognizes it as such because of this statement:\n...\n  if ((insn \u0026 0xff9000f0) !\u003d 0xe1900090)\n    return {};\n...\n\nThe trouble with this statement is that it requires knowledge of arm\ninstruction encoding to understand which cases it does and doesn\u0027t cover.\n\nNote that the corresponding comment only mentions ldrex:\n...\n  /* Assume all atomic sequences start with a ldrex{,b,h,d} instruction. ... */\n...\nbut evidently at least some forms of ldaex are also detected.\n\nSo, also use ldaex_p in arm_deal_with_atomic_sequence_raw.  This may or may\nnot be redundant, but at least ldaex_p is explicit and precise about what it\nsupports.\n\nLikewise for stlex (generated when using __ATOMIC_RELEASE instead of\n__ATOMIC_ACQUIRE in the example above).\n\nTested in arm-linux chroot on aarch64-linux.\n\nReviewed-By: Thiago Jung Bauermann \u003cthiago.bauermann@linaro.org\u003e\nCo-Authored-By: Thiago Jung Bauermann \u003cthiago.bauermann@linaro.org\u003e\nApproved-By: Luis Machado \u003cluis.machado@arm.com\u003e\n\nPR tdep/32796\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d32796\n\n[1] https://linaro.atlassian.net/browse/GNU-1541\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "8247278b74414a514d721a3bd76d1dd6db2e2aa1",
      "old_mode": 33188,
      "old_path": "gdb/arch/arm-get-next-pcs.c",
      "new_id": "82b077c6b0ad3b7b2e7705b101f367e0beb8cc37",
      "new_mode": 33188,
      "new_path": "gdb/arch/arm-get-next-pcs.c"
    },
    {
      "type": "modify",
      "old_id": "e85a1e3f327f1e435b16265ecce05d7ef7d3dac5",
      "old_mode": 33188,
      "old_path": "gdb/arch/arm.c",
      "new_id": "1843dbee61285ea52f8633f1406423fa57fda8fe",
      "new_mode": 33188,
      "new_path": "gdb/arch/arm.c"
    },
    {
      "type": "modify",
      "old_id": "5f7aa85a3c1c7d2ea6b3d456e56241a019d5acfa",
      "old_mode": 33188,
      "old_path": "gdb/arch/arm.h",
      "new_id": "d9c750329a48799f9ae231279eda162280ca8d4c",
      "new_mode": 33188,
      "new_path": "gdb/arch/arm.h"
    }
  ]
}