aboutsummaryrefslogtreecommitdiff
path: root/gdb/addrmap.c
diff options
context:
space:
mode:
authorPedro Alves <pedro@palves.net>2024-03-22 12:31:29 +0000
committerPedro Alves <pedro@palves.net>2024-03-22 12:31:29 +0000
commit431a6b091d3106bc9750d82f50535d35d760f920 (patch)
treef9e20141109e8157f1334b968d60babd99152bbd /gdb/addrmap.c
parent820a77554e64dd26d8ec2b03b59846268730c8be (diff)
downloadgdb-431a6b091d3106bc9750d82f50535d35d760f920.zip
gdb-431a6b091d3106bc9750d82f50535d35d760f920.tar.gz
gdb-431a6b091d3106bc9750d82f50535d35d760f920.tar.bz2
Teach GDB to generate sparse core files (PR corefiles/31494)
This commit teaches GDB's gcore command to generate sparse core files (if supported by the filesystem). To create a sparse file, all you have to do is skip writing zeros to the file, instead lseek'ing-ahead over them. The sparse logic is applied when writing the memory sections, as that's where the bulk of the data and the zeros are. The commit also tweaks gdb.base/bigcore.exp to make it exercise gdb-generated cores in addition to kernel-generated cores. We couldn't do that before, because GDB's gcore on that test's program would generate a multi-GB non-sparse core (16GB on my system). After this commit, gdb.base/bigcore.exp generates, when testing with GDB's gcore, a much smaller core file, roughly in line with what the kernel produces: real sizes: $ du --hu testsuite/outputs/gdb.base/bigcore/bigcore.corefile.* 2.2M testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb 2.0M testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel apparent sizes: $ du --hu --apparent-size testsuite/outputs/gdb.base/bigcore/bigcore.corefile.* 16G testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb 16G testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel Time to generate the core also goes down significantly. On my machine, I get: when writing to an SSD, from 21.0s, down to 8.0s when writing to an HDD, from 31.0s, down to 8.5s The changes to gdb.base/bigcore.exp are smaller than they look at first sight. It's basically mostly refactoring -- moving most of the code to a new procedure which takes as argument who should dump the core, and then calling the procedure twice. I purposely did not modernize any of the refactored code in this patch. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31494 Reviewed-By: Lancelot Six <lancelot.six@amd.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: John Baldwin <jhb@FreeBSD.org> Change-Id: I2554a6a4a72d8c199ce31f176e0ead0c0c76cff1
Diffstat (limited to 'gdb/addrmap.c')
0 files changed, 0 insertions, 0 deletions