About the gdb prec save/restore reverse exec behavior error (gcore error)

[Hui Zhu <teawater@gmail.com>]

Hi guys,

I found that prec save/restore reverse exec behavior error.  For example:
gdb ./a.out ./gdb_record.8810
Reading symbols from /home/teawater/gdb/a.out...done.
[New Thread 8810]
Core was generated by `/home/teawater/gdb/a.out'.
Program terminated with signal 5, Trace/breakpoint trap.
#0  main () at 1.c:20
20	       int     b = 0;
(gdb) record
Restored records from core file /home/teawater/gdb/./gdb_record.8810.
#0  main () at 1.c:20
20	       int     b = 0;
(gdb) n
21	       int     c = 1;
(gdb)
24		printf ("a = %d b = %d c = %d\n", a, b, c);
(gdb)
25	       b = cool ();
(gdb) rn

No more reverse-execution history.
main () at 1.c:20
20	       int     b = 0;

The reason is:
(gdb) rn
infrun: stop_pc = 0x7ffff7abbec1
infrun: stepped into subroutine
infrun: inserting step-resume breakpoint at 0x0  #address error
infrun:   status->kind = no-history
infrun: infwait_normal_state

No more reverse-execution history.
infrun: stop_stepping
main () at 1.c:20
20	       int     b = 0;

The address is not right because:
(gdb) info sharedlibrary
From                To                  Syms Read   Shared Object Library
0x00007ffff7ddea90  0x00007ffff7df7334  Yes (*)     /lib64/ld-linux-x86-64.so.2
(*): Shared library is missing debugging information.

Without the solib that have printf, gdb cannot find the debug message.of printf.


But current gdb way cannot get the solib message.
For example:
gdb ./a.out ./gdb_record.8810
[New Thread 8810]
Core was generated by `/home/teawater/gdb/a.out'.
Program terminated with signal 5, Trace/breakpoint trap.
#0  main () at 1.c:20
20	       int     b = 0;
(gdb) record
Restored records from core file /home/teawater/gdb/./gdb_record.8810.
#0  main () at 1.c:20
20	       int     b = 0;
(gdb) set solib-search-path
(gdb)
Not any output is because gdb cannot get any message of solib.
To get solib message need .dynamic section in
"solib-svr4.c:scan_dyntag", but this section's flags is:
  [21] .dynamic          DYNAMIC          0000000000600e40  00000e40
       00000000000001a0  0000000000000010  WA       6     0     8
It just alloc when inferior exec.  And gcore didn't save the memory of .dynamic.
So when prec restore (inferior didn't exec) cannot get the the solib message.

I found that kernel coredump have the .dynamic message:
./a.out
a.out: 2.c:5: main: Assertion `0' failed.
 (core dumped)
gdb ./a.out core
(gdb) info sharedlibrary
From                To                  Syms Read   Shared Object Library
0x00007fcc52666230  0x00007fcc5276b0e8  Yes (*)     /lib/libc.so.6
0x00007fcc529baa90  0x00007fcc529d3334  Yes (*)     /lib64/ld-linux-x86-64.so.2
(*): Shared library is missing debugging information.


Core file of gcore didn't make gdb auto load solib because in
"solib-svr4.c:scan_dyntag" get value from .dynamic section.
635		       dyn_ptr = extract_typed_address (ptr_buf, ptr_type);
(gdb) x ptr_addr
0x600ed8
(gdb) p ptr_buf
$20 = "\000\000\000\000\000\000\000"
Then gdb
But when gcore didn't save the value from this section in "gcore_copy_callback":
  /* Read-only sections are marked; we don't have to copy their contents.  */
  if ((bfd_get_section_flags (obfd, osec) & SEC_LOAD) == 0)
    return;
cat /proc/7122/maps
00400000-00401000 r-xp 00000000 08:06 4980746
  /home/teawater/gdb/a.out
00600000-00601000 r--p 00000000 08:06 4980746
  /home/teawater/gdb/a.out
00601000-00602000 rw-p 00001000 08:06 4980746
  /home/teawater/gdb/a.out
7ffff7a6c000-7ffff7bd4000 r-xp 00000000 08:06 3022954
  /lib/libc-2.9.so
7ffff7bd4000-7ffff7dd4000 ---p 00168000 08:06 3022954
  /lib/libc-2.9.so
7ffff7dd4000-7ffff7dd8000 r--p 00168000 08:06 3022954
  /lib/libc-2.9.so
7ffff7dd8000-7ffff7dd9000 rw-p 0016c000 08:06 3022954
  /lib/libc-2.9.so
7ffff7dd9000-7ffff7dde000 rw-p 7ffff7dd9000 00:00 0
7ffff7dde000-7ffff7dfe000 r-xp 00000000 08:06 3022858
  /lib/ld-2.9.so
7ffff7fd5000-7ffff7fd7000 rw-p 7ffff7fd5000 00:00 0
7ffff7ff9000-7ffff7ffc000 rw-p 7ffff7ff9000 00:00 0
7ffff7ffc000-7ffff7ffd000 r-xp 7ffff7ffc000 00:00 0                      [vdso]
7ffff7ffd000-7ffff7ffe000 r--p 0001f000 08:06 3022858
  /lib/ld-2.9.so
7ffff7ffe000-7ffff7fff000 rw-p 00020000 08:06 3022858
  /lib/ld-2.9.so
7ffffffea000-7ffffffff000 rw-p 7ffffffea000 00:00 0                      [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
  [vsyscall]



I think this is the root cause of this issue.  Sorry guys, I use a
long mail to show it.

Do you have some comment with it?

Thanks,
Hui