mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2026-08-27 00:26:02 -04:00
d29e960f01
This commit improves core generation on Linux. The issue this
addresses became apparent when dumping core of HIP programs on AMD
GPUs, but it's strictly a CPU-side issue.
The AMD GPU runtime used by HIP (and other languages) programs creates
these big mappings in every program, the size of GPU VRAM. E.g., on
gfx942 with 256GB VRAM, we end up with 256GB of such mappings:
(gdb) info proc mappings
...
0x00007fbfe7000000 0x00007fc7e7000000 0x800000000 0x0 ---p
0x00007fc7e7200000 0x00007fcfe7200000 0x800000000 0x0 ---p
0x00007fcfe7400000 0x00007fd7e7400000 0x800000000 0x0 ---p
0x00007fd7e7600000 0x00007fdfe7600000 0x800000000 0x0 ---p
0x00007fdfe7800000 0x00007fe7e7800000 0x800000000 0x0 ---p
0x00007fe7e7a00000 0x00007fefe7a00000 0x800000000 0x0 ---p
0x00007fefe7c00000 0x00007ff7e7c00000 0x800000000 0x0 ---p
...
They show up like this in /proc/pid/smaps
...
7fbfe7000000-7fc7e7000000 ---p 00000000 00:00 0
Size: 33554432 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 0 kB
Pss: 0 kB
Pss_Dirty: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
KSM: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
FilePmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
ProtectionKey: 0
VmFlags: mr mw me nr sd
...
Note the mappings in question have no backing data: the Rss: and Swap:
fields are zero. The mappings exist only to reserve VMAs on the CPU
side.
When the Linux kernel itself dumps core for such a process, here's
what objdump -h on the core shows for such mappings:
Idx Name Size VMA LMA File off Algn
...
39 load17 800000000 000070aeb3200000 0000000000000000 17555000 2**12
ALLOC, READONLY
40 load18 800000000 000070b6b3400000 0000000000000000 17555000 2**12
ALLOC, READONLY
...
GDB's gcore, not knowing the mappings contain only zeroes, reads all
their contents from inferior memory, all 256GB of it. On gfx942, that
makes the gcore command take around 1 minute when dumping a small HIP
program.
GDB's gcore currently generates load segments of these mappings like
this:
Idx Name Size VMA LMA File off Algn
...
40 load17 800000000 00007fcfe7400000 0000000000000000 101e0a7bd0 2**0
CONTENTS, ALLOC, LOAD, READONLY
41 load18 800000000 00007fd7e7600000 0000000000000000 181e0a7bd0 2**0
CONTENTS, ALLOC, LOAD, READONLY
...
The fact that GDB makes CONTENTS/LOAD segments makes it so that the
resulting core files are much larger than what the Linux kernel
produces (note "File off" column), even though it's mostly apparent
size as gdb knows how to produce sparse cores:
$ ls -als --hu core/*
440M -rw------- 1 pedalves pedalves 474M Mar 24 08:14 core/kernel.core
51M -rw-rw-r-- 1 pedalves pedalves 257G Mar 24 08:16 core/gdb-before.core
^^^^ real ^^^^ apparent
This commit teaches linux-tdep.c to identify anonymous mappings that
have no backing data from /proc/pid/smaps (which we already parse), so
that the gcore code can skip reading inferior memory for them, and
their load segments can be emitted with no CONTENTS/LOAD.
The skip-reading-inferior-memory part speeds up core dumping of small
HIP inferiors on gfx942 GPUs by a large factor. E.g.:
With:
$ time rocgdb --batch -q small-test-program \
-ex "with breakpoint pending on -- b gpu_code" \
-ex "r" \
-ex "gcore" \
-ex "k"
On gfx942, before the patch:
real 1m6.518s
user 0m5.984s
sys 1m0.218s
On gfx942, after the patch:
real 0m4.456s
user 0m2.219s
sys 0m1.829s
And the fact that we no longer emit segments with CONTENTS/LOAD makes
the resulting gdb-generated cores's apparent size be much smaller,
closer to kernel-generated core file's:
$ ls -als --hu core/*
440M -rw------- 1 pedalves pedalves 474M Mar 24 08:14 core/kernel.core
51M -rw-rw-r-- 1 pedalves pedalves 257G Mar 24 08:16 core/gdb-before.core
52M -rw-rw-r-- 1 pedalves pedalves 642M Mar 24 09:12 core/gdb-after.core
This commit also adds a new testcase that exercises both the scenario
in question (without relying on the HIP runtime), and the converse of
making sure that we don't skip dumping anonymous private PROT_NONE
mappings with backing data, by mistake.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I2cf21409af36266094bcff5614770605fab4030e
commit-id: d3d471d8
40 lines
1.5 KiB
C
40 lines
1.5 KiB
C
/* Copyright (C) 2026 Free Software Foundation, Inc.
|
|
|
|
This file is part of GDB.
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
it under the terms of the GNU General Public License as published by
|
|
the Free Software Foundation; either version 3 of the License, or
|
|
(at your option) any later version.
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
GNU General Public License for more details.
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
|
|
|
#ifndef GDB_FIND_MEMORY_REGION_H
|
|
#define GDB_FIND_MEMORY_REGION_H
|
|
|
|
#include "gdbsupport/function-view.h"
|
|
|
|
/* Process memory area starting at ADDR with length SIZE. Area is readable iff
|
|
READ is true, writable if WRITE is true, executable if EXEC is true. Area
|
|
is possibly changed against its original file based copy if MODIFIED is true.
|
|
|
|
MEMORY_TAGGED is true if the memory region contains memory tags, false
|
|
otherwise.
|
|
|
|
HOLE is true if the memory region is known to be all zeroes, false
|
|
otherwise.
|
|
|
|
Return true on success, false otherwise. */
|
|
|
|
using find_memory_region_ftype
|
|
= gdb::function_view<bool (CORE_ADDR addr, unsigned long size, bool read,
|
|
bool write, bool exec, bool modified,
|
|
bool memory_tagged, bool hole)>;
|
|
|
|
#endif /* GDB_FIND_MEMORY_REGION_H */
|