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

[Hui Zhu <teawater at gmail dot com>]

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  <teawater@gmail.com>

	* 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 <msnyder@vmware.com> 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
>
>

Attachment: fix-gcore-lib.txt
Description: Text document