About the gdb prec save/restore reverse exec behavior error (gcore error)
Hui Zhu
teawater@gmail.com
Wed Nov 4 06:56:00 GMT 2009
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
>
>
-------------- next part --------------
---
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;
More information about the Gdb
mailing list