)]}'
{
  "commit": "671c82e945f0fb02b58ee6edb47176606adfc3c0",
  "tree": "737dbb1943f506934c3c4eb6fb48aea8a844cfe8",
  "parents": [
    "44a61f1b9f1df069cb1e5de2cd3a1534280b33da"
  ],
  "author": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Mon Oct 21 16:41:54 2024 +0100"
  },
  "committer": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Tue Dec 24 14:15:25 2024 +0000"
  },
  "message": "gdb/freebsd: port core file context parsing to FreeBSD\n\nThis commit implements the gdbarch_core_parse_exec_context method for\nFreeBSD.\n\nThis is much simpler than for Linux.  On FreeBSD, at least the\nversion (13.x) that I have installer, there are additional entries in\nthe auxv vector that point directly to the argument and environment\nvectors, this makes it trivial to find this information.\n\nIf these extra auxv entries are not available on earlier FreeBSD, then\nthat\u0027s fine.  The fallback behaviour will be for GDB to act as it\nalways has up to this point, you\u0027ll just not get the extra\nfunctionality.\n\nOther differences compared to Linux are that FreeBSD has\nAT_FREEBSD_EXECPATH instead of AT_EXECFN, the AT_FREEBSD_EXECPATH is\nthe full path to the executable.  On Linux AT_EXECFN is the command\nthe user typed, so this can be a relative path.\n\nThis difference is handy as on FreeBSD we don\u0027t parse the mapped files\nfrom the core file (are they even available?).  So having the EXECPATH\nmeans we can use that as the absolute path to the executable.\n\nHowever, if the user ran a symlink then AT_FREEBSD_EXECPATH will be\nthe absolute path to the symlink, not to the underlying file.  This is\nprobably a good thing, but it does mean there is one case we test on\nLinux that fails on FreeBSD.\n\nOn Linux if we create a symlink to an executable, then run the symlink\nand generate a corefile.  Now delete the symlink and load the core\nfile.  On Linux GDB will still find (and open) the original\nexecutable.  This is because we use the mapped file information to\nfind the absolute path to the executable, and the mapped file\ninformation only stores the real file names, not symlink names.\n\nThis is a total edge case, I only added the deleted symlink test\noriginally because I could see that this would work on Linux.  Though\nit is neat that Linux finds this, I don\u0027t feel too bad that this fails\non FreeBSD.\n\nOther than this, everything seems to work on x86-64 FreeBSD (13.4)\nwhich is all I have setup right now.  I don\u0027t see why other\narchitectures wouldn\u0027t work too, but I haven\u0027t tested them.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e97ff52d5bf3c8fa0acbfe4549aebc3b49ccaca3",
      "old_mode": 33188,
      "old_path": "gdb/fbsd-tdep.c",
      "new_id": "804a72c420594b9af92cf3820944d43b91f3eab9",
      "new_mode": 33188,
      "new_path": "gdb/fbsd-tdep.c"
    },
    {
      "type": "modify",
      "old_id": "ac97754fe7136f367956e4c8b88cdf7e40c31366",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.base/corefile-exec-context.exp",
      "new_id": "73e13e60d75eca03aa403cc2dd7b292e17c9f67f",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.base/corefile-exec-context.exp"
    },
    {
      "type": "modify",
      "old_id": "40324c1f01c79dc14811b72d81e2c58b4fb6dd70",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.base/corefile-find-exec.exp",
      "new_id": "07e660d85e89498373072147f4796aef1715df9f",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.base/corefile-find-exec.exp"
    }
  ]
}