)]}'
{
  "commit": "bd9482bca71e7bf4149a319a95d6fec4589c3758",
  "tree": "ab45f8aa5885c319be238dcafa292cf917d96b28",
  "parents": [
    "3505d4c4f7e2156837c7bfcbecf0a03b202e7ffb"
  ],
  "author": {
    "name": "Pedro Alves",
    "email": "pedro@palves.net",
    "time": "Fri Nov 25 16:20:22 2022 +0000"
  },
  "committer": {
    "name": "Pedro Alves",
    "email": "pedro@palves.net",
    "time": "Mon Feb 27 19:12:28 2023 +0000"
  },
  "message": "all-stop \"follow-fork parent\" and selecting another thread\n\nWith:\n\n - catch a fork in thread 1\n - select thread 2\n - set follow-fork child\n - next\n\n... follow_fork notices that thread 1 had last stopped for a fork\nwhich hasn\u0027t been followed yet, and because thread 1 is not the\ncurrent thread, GDB aborts the execution command, presenting the stop\nin thread 1.\n\nThat makes sense, as only the forking thread (thread 1) survives in\nthe child, so better stop and let the user decide how to proceed.\n\nHowever, with:\n\n - catch a fork in thread 1\n - select thread 2\n - set follow-fork parent \u003c\u003c note difference here\n - next\n\n... GDB does the same: follow_fork notices that thread 1 had last\nstopped for a fork which hasn\u0027t been followed yet, and because thread\n1 is not the current thread, GDB aborts the execution command,\npresenting the stop in thread 1.\n\nAborting/stopping in this case doesn\u0027t make sense to me.  As we\u0027re\nfollowing the parent, thread 2 will still continue to exist in the\nparent.  What the child does after we\u0027ve followed the parent shouldn\u0027t\nmatter -- it can go on running free, be detached, etc., depending on\n\"set schedule-multiple\", \"set detach-on-fork\", etc.  That does not\ninfluence the execution command that the user issued for the parent\nthread.\n\nSo this patch changes GDB in that direction -- in follow_fork, if\nfollowing the parent, and we\u0027ve switched threads meanwhile, switch\nback to the unfollowed thread, follow it (stay with the parent), and\ndon\u0027t abort/stop.  If we\u0027re following a fork (as opposed to vfork),\nthen switch back again to the thread that the user was trying to\nresume.  If following a vfork, however, stay with the vforking-thread\nselected, as we will need to see a vfork_done event first, before we\ncan resume any other thread.\n\nAs I was working on this, I managed to end up calling target_resume\nfor a solo-thread resume (to collect the vfork_done event), with\nscope_ptid pointing at the vfork parent thread, and inferior_ptid\npointing to the vfork child.  For a solo-thread resume, the scope_ptid\nargument to target_resume must the same as inferior_ptid.  The mistake\nwas caught by the assertion in target_resume, like so:\n\n...\n  [infrun] resume_1: step\u003d0, signal\u003dGDB_SIGNAL_0, trap_expected\u003d0, current thread [1722839.1722839.0] at 0x5555555553c3\n  [infrun] do_target_resume: resume_ptid\u003d1722839.1722939.0, step\u003d0, sig\u003dGDB_SIGNAL_0\n../../src/gdb/target.c:2661: internal-error: target_resume: Assertion `inferior_ptid.matches (scope_ptid)\u0027 failed.\n...\n\nbut I think it doesn\u0027t hurt to catch such a mistake earlier, hence the\nchange in internal_resume_ptid.\n\nChange-Id: I896705506a16d2488b1bfb4736315dd966f4e412\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "04d76895f5e5ebeb95eeeea9edd1d88f52b4a158",
      "old_mode": 33188,
      "old_path": "gdb/infrun.c",
      "new_id": "beb9ca793899c555f4b6e5e7ba7026a1d4d07be1",
      "new_mode": 33188,
      "new_path": "gdb/infrun.c"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "47e8b1c7389138ac23e574214442a4ad24e4d923",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.threads/foll-fork-other-thread.c"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "ed62bfc54d912a5f34bb39ec5499be8ecaa3af85",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.threads/foll-fork-other-thread.exp"
    }
  ]
}