)]}'
{
  "commit": "b6d8d612d30dcdfc8ba8edfb15b4cd1753b0b8a2",
  "tree": "340bc482b0e131a3b14b39fb851a04c5dd324158",
  "parents": [
    "6a6859cbff7ac3fcf81689c47d19e716e9bbac2a"
  ],
  "author": {
    "name": "Kevin Buettner",
    "email": "kevinb@redhat.com",
    "time": "Tue Aug 01 13:33:24 2023 -0700"
  },
  "committer": {
    "name": "Kevin Buettner",
    "email": "kevinb@redhat.com",
    "time": "Fri Aug 11 20:54:09 2023 -0700"
  },
  "message": "gdbserver: Reinstall software single-step breakpoints in resume_stopped_resumed_lwps\n\nAt the moment, while performing a software single-step, gdbserver fails\nto reinsert software single-step breakpoints for a LWP when\ninterrupted by a signal in another thread.  This commit fixes this\nproblem by reinstalling software single-step breakpoints in\nlinux_process_target::resume_stopped_resumed_lwps in\ngdbserver/linux-low.cc.\n\nThis bug was discovered due to a failing assert in maybe_hw_step()\nin gdbserver/linux-low.cc.  Looking at the backtrace revealed\nthat the caller was linux_process_target::resume_stopped_resumed_lwps.\nI was uncertain whether the assert should still be valid when called\nfrom that method, so I tried hoisting the assert from maybe_hw_step\nto all callers except resume_stopped_resumed_lwps.  But running the\nnew test case, described below, showed that merely eliminating the\nassert for this case was NOT a good fix - a study of the log file for\nthe test showed that the single-step operation failed to occur.\nInstead GDB (via gdbserver) stopped at the next breakpoint that was\nhit.\n\nZhiyong Yan had proposed a fix which resinserted software single-step\nbreakpoints, albeit at a different location in linux-low.cc.  Testing\nrevealed that, while running gdb.threads/pending-fork-event-detach,\nthe executable associated with that test would die due to a SIGTRAP\nafter the test program was detached.  Examination of the core file(s)\nshowed that a breakpoint instruction had been left in program memory.\nTest results were otherwise very good, so Zhiyong was definitely on\nthe right track!\n\nThis commit causes software single-step breakpoint(s) to be inserted\nbefore the call to maybe_hw_step in resume_stopped_resumed_lwps.  This\nwill cause \u0027has_single_step_breakpoints (thread)\u0027 to be true, so that\nthe assert in maybe_hw_step...\n\n      /* GDBserver must insert single-step breakpoint for software\n\t single step.  */\n      gdb_assert (has_single_step_breakpoints (thread));\n\n...will no longer fail.  And better still, the single-step breakpoints\nare reinstalled, so that stepping will actually work, even when\ninterrupted.\n\nThe C code for the test case was loosely adapted from the reproducer\nprovided in Zhiyong\u0027s bug report for this problem.  The .exp file was\ncopied from next-fork-other-thread.exp and then tweaked slightly.  As\nnoted in a comment in next-fork-exec-other-thread.exp, I had to remove\n\"on\" from the loop for non-stop as it was failing on all architectures\n(including x86-64) that I tested.  I have a feeling that it ought to\nwork, but this can be investigated separately and (re)enabled once it\nworks.  I also increased the number of iterations for the loop running\nthe \"next\" commands.  I\u0027ve had some test runs which don\u0027t show the bug\nuntil the loop counter exceeded 100 iterations.  The C file for the\nnew test uses shorter delays than next-fork-other-thread.c though, so\nit doesn\u0027t take overly long (IMO) to run this new test.\n\nRunning the new test on a Raspberry Pi w/ a 32-bit (Arm) kernel and\nuserland using a gdbserver build without the fix in this commit shows\nthe following results:\n\nFAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func\u003dfork: target-non-stop\u003dauto: non-stop\u003doff: displaced-stepping\u003dauto: i\u003d12: next to other line\nFAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func\u003dfork: target-non-stop\u003dauto: non-stop\u003doff: displaced-stepping\u003don: i\u003d9: next to other line\nFAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func\u003dfork: target-non-stop\u003dauto: non-stop\u003doff: displaced-stepping\u003doff: i\u003d18: next to other line\nFAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func\u003dfork: target-non-stop\u003doff: non-stop\u003doff: displaced-stepping\u003dauto: i\u003d3: next to other line\nFAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func\u003dfork: target-non-stop\u003doff: non-stop\u003doff: displaced-stepping\u003don: i\u003d11: next to other line\nFAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func\u003dfork: target-non-stop\u003doff: non-stop\u003doff: displaced-stepping\u003doff: i\u003d1: next to other line\nFAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func\u003dvfork: target-non-stop\u003dauto: non-stop\u003doff: displaced-stepping\u003dauto: i\u003d1: next to break here\nFAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func\u003dvfork: target-non-stop\u003dauto: non-stop\u003doff: displaced-stepping\u003don: i\u003d3: next to break here\nFAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func\u003dvfork: target-non-stop\u003dauto: non-stop\u003doff: displaced-stepping\u003doff: i\u003d1: next to break here\nFAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func\u003dvfork: target-non-stop\u003don: non-stop\u003doff: displaced-stepping\u003dauto: i\u003d47: next to other line\nFAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func\u003dvfork: target-non-stop\u003don: non-stop\u003doff: displaced-stepping\u003don: i\u003d57: next to other line\nFAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func\u003dvfork: target-non-stop\u003doff: non-stop\u003doff: displaced-stepping\u003dauto: i\u003d1: next to break here\nFAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func\u003dvfork: target-non-stop\u003doff: non-stop\u003doff: displaced-stepping\u003don: i\u003d10: next to break here\nFAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func\u003dvfork: target-non-stop\u003doff: non-stop\u003doff: displaced-stepping\u003doff: i\u003d1: next to break here\n\n\t\t\u003d\u003d\u003d gdb Summary \u003d\u003d\u003d\n\n # of unexpected core files\t12\n # of expected passes\t\t3011\n # of unexpected failures\t14\n\nEach of the 12 core files were caused by the failed assertion in\nmaybe_hw_step in linux-low.c.  These correspond to 12 of the\nunexpected failures.\n\nWhen the tests are run using a gdbserver build which includes the fix\nin this commit, the results are significantly better, but not perfect:\n\nFAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func\u003dvfork: target-non-stop\u003don: non-stop\u003doff: displaced-stepping\u003dauto: i\u003d143: next to other line\nFAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func\u003dvfork: target-non-stop\u003don: non-stop\u003doff: displaced-stepping\u003don: i\u003d25: next to other line\n\n\t\t\u003d\u003d\u003d gdb Summary \u003d\u003d\u003d\n\n # of expected passes\t\t10178\n # of unexpected failures\t2\n\nI think that the two remaining failures are due to some different\nproblem.  They are also racy - I\u0027ve seen runs with no failures or only\none failure, but never more than two.  Also, those runs were conducted\nwith the loop count in next-fork-exec-other-thread.exp set to 200.\nDuring his testing of this fix and the new test case, Luis Machado\nfound that this test was taking a long time and asked about ways to\nspeed it up.  I then conducted additional tests in which I gradually\nreduced the loop count, timing each one, also noting the number of\nfailures.  With the loop count set to 30, I found that I could still\nreliably reproduce the failures that Zhiyong reported (in which, with\nthe proper settings, core files are created).  But, with the loop\ncount set to 30, the other failures noted above were much less likely\nto show up.  Anyone wishing to investigate those other failures should\nset the loop count back up to 200.\n\nRunning the new test on x86-64 and aarch64, both native and\nnative-gdbserver shows no failures.\n\nAlso, I see no regressions when running the entire test suite for\narmv7l-unknown-linux-gnueabihf (i.e.  the Raspberry Pi w/ 32-bit\nkernel+userland) with --target_board\u003dnative-gdbserver.  Additionally,\nusing --target_board\u003dnative-gdbserver, I also see no regressions for\nthe entire test suite for x86-64 and aarch64 running Fedora 38.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d30387\nCo-Authored-By: Zhiyong Yan \u003czhiyong.yan@windriver.com\u003e\nTested-By: Zhiyong Yan \u003czhiyong.yan@windriver.com\u003e\nTested-By: Luis Machado \u003cluis.machado@arm.com\u003e\n",
  "tree_diff": [
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "884706c6c3c65df55507587d445ae2bd8fcd9b3b",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.threads/next-fork-exec-other-thread.c"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "5e0ac5b78df23d1961bdbdc3dcf7fe02e92cc326",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.threads/next-fork-exec-other-thread.exp"
    },
    {
      "type": "modify",
      "old_id": "651f219b738e77107195045fd3c56af5b42a84b9",
      "old_mode": 33188,
      "old_path": "gdbserver/linux-low.cc",
      "new_id": "e1806ade82f076672d6a8d5e37b94b7ace315e71",
      "new_mode": 33188,
      "new_path": "gdbserver/linux-low.cc"
    }
  ]
}