)]}'
{
  "commit": "73d7312ff6196747ff64f74ddcc6cb1c032a68b4",
  "tree": "73d92e435d950e2b54adc00f47c70274008c1e8c",
  "parents": [
    "3da8ce337cb5d57626988e124da50013c082ed88"
  ],
  "author": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Wed Jul 31 15:50:50 2024 +0100"
  },
  "committer": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Sun Nov 10 10:18:22 2024 +0000"
  },
  "message": "gdb: use mapped file information to improve debuginfod text\n\nWhen opening a core-file GDB is able to use debuginfod to download the\nexecutable that matches the core-file if GDB can find a build-id for\nthe executable in the core-file.\n\nIn this case GDB calls debuginfod_exec_query to download the\nexecutable and GDB prints a message like:\n\n  Downloading executable for /path/to/core-file...\n\nwhich makes sense in that case.\n\nFor a long time GDB has also had the ability to download memory-mapped\nfiles and shared libraries when opening a core-file.  However, recent\ncommits have made these cases more likely to trigger, which is a good\nthing, but the messaging from GDB in these cases is not ideal.  When\ndownloading a memory-mapped file GDB prints:\n\n  Downloading executable for /path/to/memory-mapped-file\n\nAnd for a shared library:\n\n  Downloading executable for /path/to/libfoo.so\n\nThese last two messages could, I think, be improved.\n\nI propose making two changes.  First, I suggest instead of using\n/path/to/core-file in the first case, we use the name of the\nexecutable that GDB is fetching.  This makes the messaging consistent\nin that we print the name of the file we\u0027re fetching rather than the\nname of the file we\u0027re fetching something for.\n\nI further propose that we replace \u0027executable for\u0027 with the more\ngeneric word \u0027file\u0027.  The messages will then become:\n\n  Downloading file /path/to/exec-file...\n  Downloading file /path/to/memory-mapped-file...\n  Downloading file /path/to/libfoo.so...\n\nI think these messages are clearer than what we used to have, and they\nare consistent in that we name the thing being downloaded in all\ncases.\n\nThere is one tiny problem.  The first case relies on GDB knowing the\nname of the executable it wants to download.  The only place we can\ncurrently get that from is, I think, the memory-mapped file list.\n\n[ ASIDE: There is `bfd_core_file_failing_command` which reports the\n  executable and argument list from the core file, but this\n  information is not ideal for this task.  First, the executable and\n  arguments are merged into a single string, and second, the string is\n  a relatively short, fixed length string, so the executable name is\n  often truncated.  For these reasons I don\u0027t consider fetching the\n  executable name using this bfd function as a solution. ]\n\nWe do have to consider the case that the core file does not have any\nmapped file information.  This shouldn\u0027t ever be the case for a Linux\ntarget, but it\u0027s worth considering.\n\n[ ASIDE: I mention Linux specifically because this only becomes a\n  problem if we try to do a lookup via debuginfod, which requires that\n  we have build-ids available.  Linux has special support for\n  embedding build-ids into the core file, but I\u0027m not sure if other\n  kernels do this. ]\n\nFor the unlikely edge case of a core-file that has build-ids, but\ndoesn\u0027t have any mapped file information then I propose that we\nsynthesis a filename like: \u0027with build-id xxxxxx\u0027.  We would then see\na message like:\n\n  Downloading file with build-id xxxxxx...\n\nWhere \u0027xxxxxx\u0027 would be replaced by the actual build-id.\n\nThis isn\u0027t ideal, but I think is good enough, and, as I said, I think\nthis case is not going to be hit very often, or maybe at all.\n\nWe already had some tests that emitted two of the above messages,\nwhich I\u0027ve updated, these cover the mapped-file and shared library\ncase.\n\nThe message about downloading the exec for the core-file is actually\nreally hard to trigger now as usually the exec will also appear in the\nmemory-mapped file list and GDB will download the file at this stage.\nThen when GDB needs the executable for loading the symbols it\u0027ll ask\ndebuginfod, and debuginfod will find the file in its cache, and so no\nmessage will be printed.\n\nIf anyone has any ideas about how to trigger this case then I\u0027m happy\nto add additional tests.\n\nApproved-By: Tom Tromey \u003ctom@tromey.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "5820ffed3322cc44d5ebc1417db8c78bdac9b015",
      "old_mode": 33188,
      "old_path": "gdb/corelow.c",
      "new_id": "87ce04d6852922b67a11f883d855c9fcac5fb5b5",
      "new_mode": 33188,
      "new_path": "gdb/corelow.c"
    },
    {
      "type": "modify",
      "old_id": "841b6f2078c71b8040cc4946b3e4a39863dec460",
      "old_mode": 33188,
      "old_path": "gdb/debuginfod-support.c",
      "new_id": "9460ae18dd676c811fd7140bcd434dd41a041d21",
      "new_mode": 33188,
      "new_path": "gdb/debuginfod-support.c"
    },
    {
      "type": "modify",
      "old_id": "cf96b41ac9a1ed093de7611193b4a454e1bbb839",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.debuginfod/corefile-mapped-file.exp",
      "new_id": "cad70aaa3c669abb03c74fecfb8f6518f6a6799a",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.debuginfod/corefile-mapped-file.exp"
    },
    {
      "type": "modify",
      "old_id": "9ef12041dc6a4793cbc40680c96e00a2496a8c0c",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.debuginfod/solib-with-soname.exp",
      "new_id": "31ca7181af6558fe4616b11d911b738481a40a35",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.debuginfod/solib-with-soname.exp"
    }
  ]
}