)]}'
{
  "commit": "95cb8bf72b6f75e5b672131389ff7496bfa47ebe",
  "tree": "269cc87f7134d5d78af1a1ab3701e52c8bb966e5",
  "parents": [
    "5c18eb6bb54242d61fd03aa781e20f91c8c30d72"
  ],
  "author": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Sat Sep 23 14:29:40 2023 +0100"
  },
  "committer": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Thu Oct 05 12:21:45 2023 +0100"
  },
  "message": "gdb: use archive name in warning when appropriate\n\nWhile working on some other patch I noticed that in reread_symbols\nthere is a diagnostic message that can be printed, and in some cases\nwe might use the wrong filename in the message.\n\nThe code in question is checking to see if an objfile has changed on\ndisk, we do this by stat-ing the on disk file and checking the mtime.\nIf this file has been removed from disk then we print a message that\nthe file has been removed, however, if the objfile is within an\narchive then we stat the archive itself, but then warn that the\ncomponent within the archive has disappeared.  I think it makes more\nsense to say that the archive has disappeared.\n\nThe last related commit is this one:\n\n  commit 02aeec7bde8ec8a04d14a5637e75f1c6ab899e23\n  Date:   Tue Apr 27 21:01:30 2010 +0000\n\n      Check library name rather than member name when rereading symbols.\n\nThough this just makes the code to stat the archive unconditional, the\ncode in question existed before this commit.\n\nHowever, the above commit doesn\u0027t include any tests, and seems to\nindicate that the problem being addressed was seen on Darwin.  I\u0027m not\nsure how to setup a test where GDB is using an objfile from within an\narchive, and so there\u0027s no tests for this commit...\n\n... but if someone can let me know how I can setup a suitable test,\nplease let me know and I\u0027ll try to get something working.\n\nApproved-By: Tom Tromey \u003ctom@tromey.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "0338825d3fbcd3c777d1725bd1d722ab90a983c8",
      "old_mode": 33188,
      "old_path": "gdb/symfile.c",
      "new_id": "ff8a3fd0bc55a5ab21026c084ad86d0639b47a69",
      "new_mode": 33188,
      "new_path": "gdb/symfile.c"
    }
  ]
}