Hi, When GDB is used to generate a core dump file, that core dump contains much less information about the crashed target's memory mappings. All of this can be seen and reproduced with the steps below. ``` $ echo 'int main() { int *x = (int*)0x41414141; *x = 0x42424242; }' | gcc -xc - $ gdb --quiet --nx -ex 'run' -ex 'info proc mappings' -ex 'generate-core-file' ./a.out Reading symbols from ./a.out... (No debugging symbols found in ./a.out) Starting program: /home/user/a.out [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x000055555555513d in main () process 75421 Mapped address spaces: Start Addr End Addr Size Offset Perms objfile 0x555555554000 0x555555555000 0x1000 0x0 r--p /home/user/a.out 0x555555555000 0x555555556000 0x1000 0x1000 r-xp /home/user/a.out 0x555555556000 0x555555557000 0x1000 0x2000 r--p /home/user/a.out 0x555555557000 0x555555558000 0x1000 0x2000 r--p /home/user/a.out 0x555555558000 0x555555559000 0x1000 0x3000 rw-p /home/user/a.out 0x7ffff7d80000 0x7ffff7d83000 0x3000 0x0 rw-p 0x7ffff7d83000 0x7ffff7dab000 0x28000 0x0 r--p /usr/lib/x86_64-linux-gnu/libc.so.6 0x7ffff7dab000 0x7ffff7f40000 0x195000 0x28000 r-xp /usr/lib/x86_64-linux-gnu/libc.so.6 0x7ffff7f40000 0x7ffff7f98000 0x58000 0x1bd000 r--p /usr/lib/x86_64-linux-gnu/libc.so.6 0x7ffff7f98000 0x7ffff7f9c000 0x4000 0x214000 r--p /usr/lib/x86_64-linux-gnu/libc.so.6 0x7ffff7f9c000 0x7ffff7f9e000 0x2000 0x218000 rw-p /usr/lib/x86_64-linux-gnu/libc.so.6 0x7ffff7f9e000 0x7ffff7fab000 0xd000 0x0 rw-p 0x7ffff7fbb000 0x7ffff7fbd000 0x2000 0x0 rw-p 0x7ffff7fbd000 0x7ffff7fc1000 0x4000 0x0 r--p [vvar] 0x7ffff7fc1000 0x7ffff7fc3000 0x2000 0x0 r-xp [vdso] 0x7ffff7fc3000 0x7ffff7fc5000 0x2000 0x0 r--p /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 0x7ffff7fc5000 0x7ffff7fef000 0x2a000 0x2000 r-xp /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 0x7ffff7fef000 0x7ffff7ffa000 0xb000 0x2c000 r--p /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 0x7ffff7ffb000 0x7ffff7ffd000 0x2000 0x37000 r--p /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 0x7ffff7ffd000 0x7ffff7fff000 0x2000 0x39000 rw-p /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 0x7ffffffde000 0x7ffffffff000 0x21000 0x0 rw-p [stack] 0xffffffffff600000 0xffffffffff601000 0x1000 0x0 --xp [vsyscall] warning: Memory read failed for corefile section, 4096 bytes at 0xffffffffff600000. Saved corefile core.75421 (gdb) $ gdb --quiet --nx -core ./core.75421 -ex 'info proc mappings' [New LWP 75421] Core was generated by `/home/user/a.out'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000055555555513d in ?? () Mapped address spaces: Start Addr End Addr Size Offset objfile 0x555555554000 0x555555555000 0x1000 0x0 /home/user/a.out 0x555555555000 0x555555556000 0x1000 0x1000 /home/user/a.out 0x555555556000 0x555555557000 0x1000 0x2000 /home/user/a.out 0x555555557000 0x555555558000 0x1000 0x2000 /home/user/a.out 0x555555558000 0x555555559000 0x1000 0x3000 /home/user/a.out 0x7ffff7d83000 0x7ffff7dab000 0x28000 0x0 /usr/lib/x86_64-linux-gnu/libc.so.6 0x7ffff7dab000 0x7ffff7f40000 0x195000 0x28000 /usr/lib/x86_64-linux-gnu/libc.so.6 0x7ffff7f40000 0x7ffff7f98000 0x58000 0x1bd000 /usr/lib/x86_64-linux-gnu/libc.so.6 0x7ffff7f98000 0x7ffff7f9c000 0x4000 0x214000 /usr/lib/x86_64-linux-gnu/libc.so.6 0x7ffff7f9c000 0x7ffff7f9e000 0x2000 0x218000 /usr/lib/x86_64-linux-gnu/libc.so.6 0x7ffff7fc3000 0x7ffff7fc5000 0x2000 0x0 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 0x7ffff7fc5000 0x7ffff7fef000 0x2a000 0x2000 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 0x7ffff7fef000 0x7ffff7ffa000 0xb000 0x2c000 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 0x7ffff7ffb000 0x7ffff7ffd000 0x2000 0x37000 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 0x7ffff7ffd000 0x7ffff7fff000 0x2000 0x39000 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (gdb) ``` Paying close attention, the corefile's `info proc mappings` shows only the a.out, libc.so.6 and ld.so.2 maps, so it lacks information about heap, stack, vvar, vdso, vsyscall and other anonymous and unnamed mappings. All this hinders the ability to debug a process properly and often causes issues for GDB plugins developers (like me) who have to work around those issues. One workaround here is to use the `maintenance info sections` command information and parse it. However, this is far from perfect. While it contains the [start,end) ranges of the missing memory mappings and their memory protections (which, sadly the `info proc mappings` does not display here) it still lacks the names of those mappings. ``` (gdb) maintenance info sections Core file: `/home/user/./core.75421', file type elf64-x86-64. [0] 0x00000000->0x00002c00 at 0x00098430: note0 READONLY HAS_CONTENTS [1] 0x00000000->0x000000d8 at 0x00098550: .reg/75421 HAS_CONTENTS [2] 0x00000000->0x000000d8 at 0x00098550: .reg HAS_CONTENTS [3] 0x00000000->0x00000200 at 0x00098644: .reg2/75421 HAS_CONTENTS [4] 0x00000000->0x00000200 at 0x00098644: .reg2 HAS_CONTENTS [5] 0x00000000->0x00000340 at 0x00098858: .reg-xstate/75421 HAS_CONTENTS [6] 0x00000000->0x00000340 at 0x00098858: .reg-xstate HAS_CONTENTS [7] 0x00000000->0x00000080 at 0x00098bac: .note.linuxcore.siginfo/75421 HAS_CONTENTS [8] 0x00000000->0x00000080 at 0x00098bac: .note.linuxcore.siginfo HAS_CONTENTS [9] 0x00000000->0x00000150 at 0x00098c40: .auxv HAS_CONTENTS [10] 0x00000000->0x0000036c at 0x00098da4: .note.linuxcore.file/75421 HAS_CONTENTS [11] 0x00000000->0x0000036c at 0x00098da4: .note.linuxcore.file HAS_CONTENTS [12] 0x00000000->0x00001f10 at 0x00099120: .gdb-tdesc/75421 HAS_CONTENTS [13] 0x00000000->0x00001f10 at 0x00099120: .gdb-tdesc HAS_CONTENTS [14] 0x555555554000->0x555555555000 at 0x00000430: load1 ALLOC LOAD READONLY HAS_CONTENTS [15] 0x555555555000->0x555555556000 at 0x00001430: load2 ALLOC LOAD READONLY CODE HAS_CONTENTS [16] 0x555555557000->0x555555558000 at 0x00002430: load3 ALLOC LOAD READONLY HAS_CONTENTS [17] 0x555555558000->0x555555559000 at 0x00003430: load4 ALLOC LOAD HAS_CONTENTS [18] 0x7ffff7d80000->0x7ffff7d83000 at 0x00004430: load5 ALLOC LOAD HAS_CONTENTS [19] 0x7ffff7d83000->0x7ffff7dab000 at 0x00007430: load6 ALLOC LOAD READONLY HAS_CONTENTS [20] 0x7ffff7f98000->0x7ffff7f9c000 at 0x0002f430: load7 ALLOC LOAD READONLY HAS_CONTENTS [21] 0x7ffff7f9c000->0x7ffff7f9e000 at 0x00033430: load8 ALLOC LOAD HAS_CONTENTS [22] 0x7ffff7f9e000->0x7ffff7fab000 at 0x00035430: load9 ALLOC LOAD HAS_CONTENTS [23] 0x7ffff7fbb000->0x7ffff7fbd000 at 0x00042430: load10 ALLOC LOAD HAS_CONTENTS [24] 0x7ffff7fc1000->0x7ffff7fc3000 at 0x00044430: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS [25] 0x7ffff7fc3000->0x7ffff7fc5000 at 0x00046430: load12 ALLOC LOAD READONLY HAS_CONTENTS [26] 0x7ffff7fc5000->0x7ffff7fef000 at 0x00048430: load13 ALLOC LOAD READONLY CODE HAS_CONTENTS [27] 0x7ffff7ffb000->0x7ffff7ffd000 at 0x00072430: load14 ALLOC LOAD READONLY HAS_CONTENTS [28] 0x7ffff7ffd000->0x7ffff7fff000 at 0x00074430: load15 ALLOC LOAD HAS_CONTENTS [29] 0x7ffffffde000->0x7ffffffff000 at 0x00076430: load16 ALLOC LOAD HAS_CONTENTS [30] 0xffffffffff600000->0xffffffffff601000 at 0x00097430: load17 ALLOC LOAD READONLY CODE HAS_CONTENTS ``` Anyway, can anyone fix this please?
Also, please note that the `info proc mappings` should also display the `Perms` column but it does not.