)]}'
{
  "commit": "0726729d344fecf98f8d138e688e77201cc3cece",
  "tree": "1cf3b0e2eb25a84a912d96a7c89082dfbbdd2a3b",
  "parents": [
    "8db172ae38714452e2b36f66988c560c9ce69fc0"
  ],
  "author": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Mon Jun 03 13:56:54 2024 +0100"
  },
  "committer": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Sun Jul 28 09:51:52 2024 +0100"
  },
  "message": "gdb/testsuite: track if a caching proc calls gdb_exit or not\n\nAfter a recent patch review I asked myself why can_spawn_for_attach\nexists.  This proc currently does some checks, and then calls\ncan_spawn_for_attach_1 which is an actual caching proc.\n\nThe answer is that can_spawn_for_attach exists in order to call\ngdb_exit the first time can_spawn_for_attach is called within any test\nscript.\n\nThe reason this is useful is that can_spawn_for_attach_1 calls\ngdb_exit.  If the user calls can_spawn_for_attach_1 directly then a\nproblem might exist.  Imagine a test written like this:\n\n  gdb_start\n\n  if { [can_spawn_for_attach_1] } {\n    ... do stuff that assumes GDB is running ...\n  }\n\nIf this test is NOT the first test run, and if an earlier test calls\ncan_spawn_for_attach_1, then when the above test is run the\ncan_spawn_for_attach_1 call will return the cached value and gdb_exit\nwill not be called.\n\nBut, if the above test IS the first test run then\ncan_spawn_for_attach_1 will not return the cached value, but will\ninstead compute the cached value, a process that ends up calling\ngdb_exit.  When can_spawn_for_attach_1 returns GDB will have exited\nand the test might fail if it is written assuming that GDB is\nrunning.\n\nSo can_spawn_for_attach was added which ensures that we _always_ call\ngdb_exit the first time can_spawn_for_attach is called within a single\ntest script, this ensures that in the above case, even if the above is\nnot the first test script run, gdb_exit will still be called.  This\nensures consistent behaviour and avoids some hidden bugs in the\ntestsuite.\n\nThe split between can_spawn_for_attach and can_spawn_for_attach_1 was\nintroduced in this commit:\n\n  commit 147fe7f9fb9a89b217d11d73053f53e8edacf90f\n  Date:   Mon May 6 14:27:09 2024 +0200\n\n      [gdb/testsuite] Handle ptrace operation not permitted in can_spawn_for_attach\n\nHowever, I observe that can_spawn_for_attach is not the only caching\nproc that calls gdb_exit.  Why does can_spawn_for_attach get special\ntreatment when surely the same issue exists for any other caching proc\nthat calls gdb_exit?\n\nI think a better solution is to move the logic from\ncan_spawn_for_attach into cache.exp and generalise it so that it\napplies to all caching procs.\n\nThis commit does this by:\n\n 1. When the underlying caching proc is executed we track calls to\n    gdb_exit.  If a caching proc calls gdb_exit then this information\n    is stored in gdb_data_cache (using a \u0027,exit\u0027 suffix), and also\n    written to the cache file if appropriate.\n\n 2. When a cached value is returned from gdb_do_cache, if the\n    underlying proc would have called gdb_exit, and if this is the\n    first use of the caching proc in this test script, then we call\n    gdb_exit.\n\nWhen storing the \u0027,exit\u0027 value into the on-disk cache file, the flag\nvalue is stored on a second line.  Currently every cached value only\noccupies a single line, and a check is added to ensure this remains\ntrue in the future.\n\nTo track calls to gdb_exit I eventually settled on using TCL\u0027s trace\nmechanism.  We already make use of this in lib/gdb.exp so I figure\nthis is OK to use.  This should be fine, so long as non of the caching\nprocs use \u0027with_override\u0027 to replace gdb_exit, or do any other proc\nreplacement to change gdb_exit, however, I think that is pretty\nunlikely.\n\nOne issue did come up in testing, a FAIL in gdb.base/break-interp.exp,\nprior to this commit can_spawn_for_attach would call gdb_exit before\ncalling the underlying caching proc.  After this call we call gdb_exit\nafter calling the caching proc.\n\nThe underlying caching proc relies on gdb_exit having been called.  To\nresolve this issue I just added a call to gdb_exit into\ncan_spawn_for_attach.\n\nWith this done can_spawn_for_attach_1 can be renamed to\ncan_spawn_for_attach, and the existing can_spawn_for_attach can be\ndeleted.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e7b9114058b133612d35cc527290f85173cf7bbe",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/lib/cache.exp",
      "new_id": "092b7f136e86b89a80f21e8329d6582d7664495c",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/lib/cache.exp"
    },
    {
      "type": "modify",
      "old_id": "e5cacefeb134787eab3959e6c1631fa8819acb77",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/lib/gdb.exp",
      "new_id": "b3e1f306a292f2ffeecf3e2fb6b36445175c9f9b",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/lib/gdb.exp"
    }
  ]
}