Bug 29508 - gdb generate-core does not save all memory maps information
Summary: gdb generate-core does not save all memory maps information
Status: UNCONFIRMED
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-08-19 23:18 UTC by Disconnect3d
Modified: 2022-08-31 01:09 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Disconnect3d 2022-08-19 23:18:33 UTC
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?
Comment 1 Disconnect3d 2022-08-19 23:25:27 UTC
Also, please note that the `info proc mappings` should also display the `Perms` column but it does not.