From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2627 invoked by alias); 31 Oct 2009 17:07:11 -0000 Received: (qmail 2617 invoked by uid 22791); 31 Oct 2009 17:07:10 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pw0-f49.google.com (HELO mail-pw0-f49.google.com) (209.85.160.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 31 Oct 2009 17:07:06 +0000 Received: by pwj3 with SMTP id 3so1257821pwj.8 for ; Sat, 31 Oct 2009 10:07:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.4.38 with SMTP id 38mr298125wfd.119.1257008825061; Sat, 31 Oct 2009 10:07:05 -0700 (PDT) From: Hui Zhu Date: Sat, 31 Oct 2009 17:41:00 -0000 Message-ID: Subject: About the gdb prec save/restore reverse exec behavior error (gcore error) To: gdb@sourceware.org Cc: Michael Snyder Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00415.txt.bz2 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