)]}'
{
  "commit": "37cb3cd8f896b8d0aa95ced818c6c7b1fb9ddc99",
  "tree": "97f2e0b79469de8fb66fb533c2f948f7dad2dccc",
  "parents": [
    "1357605123d7cda93a0fa0364af04f387f509de3"
  ],
  "author": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Wed Mar 11 11:45:42 2026 +0000"
  },
  "committer": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Fri May 01 19:56:56 2026 +0100"
  },
  "message": "gdb/linux: handle missing NT_FILE note when opening core files\n\nThis patch originated from this mailing list discussion:\n\n  https://inbox.sourceware.org/gdb-patches/b9b5bf03c59b58e02ca27b522338c6103d5ae49f.camel@gnu.org\n\nThe user has some core files which lack an NT_FILE note.  They\nwondered why GDB was still unable to find the shared libraries based\non their build-id.\n\nThe reason right now is that GDB only records the build-id information\nfor mappings based on the entries in the NT_FILE note.  With the\nentries in this note we build several lookup tables; a filename to\nbuild-id table, a soname (extracted from the file if it is a shared\nlibrary) to build-id table, and an address range to build-id table.\n\nWhen a shared library is being loaded we perform a lookup using two\npieces of information; the shared library\u0027s filename, and an address\nthat we know is within the shared library.  If either of these give a\nbuild-id, then we can use that build-id to ensure GDB loads the\nshared library that matches the core file.\n\nIf the NT_FILE note is missing then none of the lookup tables are\ncreated, and so the shared library build-id lookup fails, meaning that\nall GDB can do is look for the shared library by name on the local\nfile system.  This often results in the wrong library version being\nloaded, or the library not being found at all.\n\nHowever, Linux core files also have the segment table.  This table\ngives address ranges.  The segment table doesn\u0027t tell us what file was\nmapped in, or the offset within the file that was mapped in.  But if\nwe go back to the three lookup tables, we can use the segment table to\nbuild the address to build-id lookup table, and that would be enough\nto allow GDB to find the build-id for a shared library in most cases.\n\nSo, here\u0027s what this patch does: linux_read_core_file_mappings (in\nlinux-tdep.c) is updated to first parse the NT_FILE note as it\ncurrently does.  But after this we also walk the segment table (BFD\nactually converts these into sections with the LOAD flag set), and if\na segment has a build-id, and doesn\u0027t correspond to an entry found in\nthe NT_FILE note, we create an anonymous mapping.  An anonymous\nmapping is just like a mapping from the NT_FILE note, but without a\nfilename and file offset.  This mapping is passed through the callback\njust like the traditional, non-anonymous, mappings.\n\nThen in corelow.c various functions are updated in order to handle\nanonymous mappings.\n\nBack in linux-tdep.c, function linux_core_info_proc_mappings gets a\nsmall update to handle anonymous mappings.\n\nThe corefile-buildid.exp test is updated to remove the NT_FILE notes\nand rerun the tests.  This should make no difference as all this test\nis checking is that GDB is able to find and load the shared libraries\nand executable based on their build-ids; this is something we can do\nfine now without the NT_FILE note.\n\nI have also had to update the Python core file API documentation after\nthis commit.  Previously we claimed that CorefileMappedFile.filename\nwould never be empty, but this is now possible.  Luckily, this API has\nnot yet been in a released version of GDB, so this minor tweak isn\u0027t\ngoing to break any existing user code.  I did consider having\nCorefileMappedFile.filename be a non-empty string or None, but I\ncouldn\u0027t see much value in this, so I just documented that the string\ncould be empty, and what this means.\n\nThe py-corefile.exp test needed a minor update to filter out anonymous\nmappings (those without a filename), this matches the behaviour of the\nbuiltin \u0027info proc mappings\u0027 command.\n\nReviewed-By: Keith Seitz \u003ckeiths@redhat.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "407515ee45ad9d80462abc91d5fdb3234f73c2db",
      "old_mode": 33188,
      "old_path": "gdb/corelow.c",
      "new_id": "008da68155f6fbdcdbbbd3d7e845c8dc7eb840ab",
      "new_mode": 33188,
      "new_path": "gdb/corelow.c"
    },
    {
      "type": "modify",
      "old_id": "96b46a98091674bb1b852628b86fc671ea4145bb",
      "old_mode": 33188,
      "old_path": "gdb/doc/python.texi",
      "new_id": "6cafab78d5893903ecfe6d0308e7563061c9787f",
      "new_mode": 33188,
      "new_path": "gdb/doc/python.texi"
    },
    {
      "type": "modify",
      "old_id": "89586e0c6ecff3a5045ba0321a54dd22e6d9eb16",
      "old_mode": 33188,
      "old_path": "gdb/gdbcore.h",
      "new_id": "3fd91770c548fab5bd132ce0c8b7b49f156b5fef",
      "new_mode": 33188,
      "new_path": "gdb/gdbcore.h"
    },
    {
      "type": "modify",
      "old_id": "43df05d1529a24ee5435f1a6a99f161ee3a760b1",
      "old_mode": 33188,
      "old_path": "gdb/linux-tdep.c",
      "new_id": "4bc5a2b6948448ce768ec4947f61e4febfcde21c",
      "new_mode": 33188,
      "new_path": "gdb/linux-tdep.c"
    },
    {
      "type": "modify",
      "old_id": "09935c2a86e28286b2668780037d7ed32d78b4fc",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.base/corefile-buildid.exp",
      "new_id": "5207cc15816fe417c099538741b006725cd29f69",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.base/corefile-buildid.exp"
    },
    {
      "type": "modify",
      "old_id": "aadcfc4acb27113202c161f4885bd9002be69ce5",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.python/py-corefile.py",
      "new_id": "de6d85fffc182742c6008efdd06d9ca3f1885801",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.python/py-corefile.py"
    }
  ]
}