)]}'
{
  "commit": "431a6b091d3106bc9750d82f50535d35d760f920",
  "tree": "f9e20141109e8157f1334b968d60babd99152bbd",
  "parents": [
    "820a77554e64dd26d8ec2b03b59846268730c8be"
  ],
  "author": {
    "name": "Pedro Alves",
    "email": "pedro@palves.net",
    "time": "Fri Mar 22 12:31:29 2024 +0000"
  },
  "committer": {
    "name": "Pedro Alves",
    "email": "pedro@palves.net",
    "time": "Fri Mar 22 12:31:29 2024 +0000"
  },
  "message": "Teach GDB to generate sparse core files (PR corefiles/31494)\n\nThis commit teaches GDB\u0027s gcore command to generate sparse core files\n(if supported by the filesystem).\n\nTo create a sparse file, all you have to do is skip writing zeros to\nthe file, instead lseek\u0027ing-ahead over them.\n\nThe sparse logic is applied when writing the memory sections, as\nthat\u0027s where the bulk of the data and the zeros are.\n\nThe commit also tweaks gdb.base/bigcore.exp to make it exercise\ngdb-generated cores in addition to kernel-generated cores.  We\ncouldn\u0027t do that before, because GDB\u0027s gcore on that test\u0027s program\nwould generate a multi-GB non-sparse core (16GB on my system).\n\nAfter this commit, gdb.base/bigcore.exp generates, when testing with\nGDB\u0027s gcore, a much smaller core file, roughly in line with what the\nkernel produces:\n\n real sizes:\n\n $ du --hu testsuite/outputs/gdb.base/bigcore/bigcore.corefile.*\n 2.2M    testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb\n 2.0M    testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel\n\n apparent sizes:\n\n $ du --hu --apparent-size testsuite/outputs/gdb.base/bigcore/bigcore.corefile.*\n 16G     testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb\n 16G     testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel\n\nTime to generate the core also goes down significantly.  On my machine, I get:\n\n  when writing to an SSD, from 21.0s, down to 8.0s\n  when writing to an HDD, from 31.0s, down to 8.5s\n\nThe changes to gdb.base/bigcore.exp are smaller than they look at\nfirst sight.  It\u0027s basically mostly refactoring -- moving most of the\ncode to a new procedure which takes as argument who should dump the\ncore, and then calling the procedure twice.  I purposely did not\nmodernize any of the refactored code in this patch.\n\nBug: https://sourceware.org/bugzilla/show_bug.cgi?id\u003d31494\nReviewed-By: Lancelot Six \u003clancelot.six@amd.com\u003e\nReviewed-By: Eli Zaretskii \u003celiz@gnu.org\u003e\nReviewed-By: John Baldwin \u003cjhb@FreeBSD.org\u003e\nChange-Id: I2554a6a4a72d8c199ce31f176e0ead0c0c76cff1\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "d8ac0bb06a754092db03e14d88c0116a15a9b02c",
      "old_mode": 33188,
      "old_path": "gdb/NEWS",
      "new_id": "d1d25e4c24d9ab682d30f0a154267765a31641d8",
      "new_mode": 33188,
      "new_path": "gdb/NEWS"
    },
    {
      "type": "modify",
      "old_id": "f093ee269e272ceb499c5f6e77238363bdc5563e",
      "old_mode": 33188,
      "old_path": "gdb/doc/gdb.texinfo",
      "new_id": "9224829bd933075c7e336ac4de07d1ab3f5cc7f3",
      "new_mode": 33188,
      "new_path": "gdb/doc/gdb.texinfo"
    },
    {
      "type": "modify",
      "old_id": "7c12aa3a777d8fbb3bb1e20162e985254b5837af",
      "old_mode": 33188,
      "old_path": "gdb/gcore.c",
      "new_id": "3d3973bfaba18973337a98e3d6a583dfb63e6a8c",
      "new_mode": 33188,
      "new_path": "gdb/gcore.c"
    },
    {
      "type": "modify",
      "old_id": "3f9ae48abf276c8d6f0afc691fadb058de54698c",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.base/bigcore.exp",
      "new_id": "6c64d402502281dd4802868c48635b37899fd5f1",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.base/bigcore.exp"
    }
  ]
}