Hi Michael, I make a patch to fix it. I try in i386-ubuntu. It is OK now. Please help me review it. Thanks, Hui 2009-11-04 Hui Zhu * gcore.c (gcore_copy_callback): Remove bfd_get_section_flags check. --- gcore.c | 4 ---- 1 file changed, 4 deletions(-) --- a/gcore.c +++ b/gcore.c @@ -510,10 +510,6 @@ gcore_copy_callback (bfd *obfd, asection struct cleanup *old_chain = NULL; void *memhunk; - /* Read-only sections are marked; we don't have to copy their contents. */ - if ((bfd_get_section_flags (obfd, osec) & SEC_LOAD) == 0) - return; - /* Only interested in "load" sections. */ if (strncmp ("load", bfd_section_name (obfd, osec), 4) != 0) return; On Sun, Nov 1, 2009 at 01:32, Michael Snyder wrote: > Hi Hui, > > Nice job of diagnostics.  You feel up to fixing it? > This would be a nice fix for gcore as well. > > Michael > > Hui Zhu wrote: >> >> 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 > >