From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7137 invoked by alias); 4 Nov 2009 06:56:20 -0000 Received: (qmail 7128 invoked by uid 22791); 4 Nov 2009 06:56:19 -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-px0-f189.google.com (HELO mail-px0-f189.google.com) (209.85.216.189) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Nov 2009 06:56:14 +0000 Received: by pxi27 with SMTP id 27so4719154pxi.25 for ; Tue, 03 Nov 2009 22:56:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.143.24.38 with SMTP id b38mr113845wfj.254.1257317773113; Tue, 03 Nov 2009 22:56:13 -0800 (PST) In-Reply-To: <4AEC74B8.9090908@vmware.com> References: <4AEC74B8.9090908@vmware.com> From: Hui Zhu Date: Wed, 04 Nov 2009 06:56:00 -0000 Message-ID: Subject: Re: About the gdb prec save/restore reverse exec behavior error (gcore error) To: Michael Snyder Cc: "gdb@sourceware.org" Content-Type: multipart/mixed; boundary=001636e1f9953c7b120477861b31 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-11/txt/msg00034.txt.bz2 --001636e1f9953c7b120477861b31 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-length: 6213 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 =3D 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) =3D=3D 0) - return; - /* Only interested in "load" sections. */ if (strncmp ("load", bfd_section_name (obfd, osec), 4) !=3D 0) return; On Sun, Nov 1, 2009 at 01:32, Michael Snyder wrote: > Hi Hui, > > Nice job of diagnostics. =A0You 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. =A0For examp= le: >> 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 =A0main () at 1.c:20 >> 20 =A0 =A0 =A0 =A0 =A0 =A0 int =A0 =A0 b =3D 0; >> (gdb) record >> Restored records from core file /home/teawater/gdb/./gdb_record.8810. >> #0 =A0main () at 1.c:20 >> 20 =A0 =A0 =A0 =A0 =A0 =A0 int =A0 =A0 b =3D 0; >> (gdb) n >> 21 =A0 =A0 =A0 =A0 =A0 =A0 int =A0 =A0 c =3D 1; >> (gdb) >> 24 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf ("a =3D %d b =3D %d c =3D %d\n", a,= b, c); >> (gdb) >> 25 =A0 =A0 =A0 =A0 =A0 =A0 b =3D cool (); >> (gdb) rn >> >> No more reverse-execution history. >> main () at 1.c:20 >> 20 =A0 =A0 =A0 =A0 =A0 =A0 int =A0 =A0 b =3D 0; >> >> The reason is: >> (gdb) rn >> infrun: stop_pc =3D 0x7ffff7abbec1 >> infrun: stepped into subroutine >> infrun: inserting step-resume breakpoint at 0x0 =A0#address error >> infrun: =A0 status->kind =3D no-history >> infrun: infwait_normal_state >> >> No more reverse-execution history. >> infrun: stop_stepping >> main () at 1.c:20 >> 20 =A0 =A0 =A0 =A0 =A0 =A0 int =A0 =A0 b =3D 0; >> >> The address is not right because: >> (gdb) info sharedlibrary >> From =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0To =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Syms Read =A0 Shared Object Library >> 0x00007ffff7ddea90 =A00x00007ffff7df7334 =A0Yes (*) >> /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 =A0main () at 1.c:20 >> 20 =A0 =A0 =A0 =A0 =A0 =A0 int =A0 =A0 b =3D 0; >> (gdb) record >> Restored records from core file /home/teawater/gdb/./gdb_record.8810. >> #0 =A0main () at 1.c:20 >> 20 =A0 =A0 =A0 =A0 =A0 =A0 int =A0 =A0 b =3D 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: >> =A0[21] .dynamic =A0 =A0 =A0 =A0 =A0DYNAMIC =A0 =A0 =A0 =A0 =A0000000000= 0600e40 =A000000e40 >> =A0 =A0 =A0 00000000000001a0 =A00000000000000010 =A0WA =A0 =A0 =A0 6 =A0= =A0 0 =A0 =A0 8 >> It just alloc when inferior exec. =A0And 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. >> =A0(core dumped) >> gdb ./a.out core >> (gdb) info sharedlibrary >> From =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0To =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Syms Read =A0 Shared Object Library >> 0x00007fcc52666230 =A00x00007fcc5276b0e8 =A0Yes (*) =A0 =A0 /lib/libc.so= .6 >> 0x00007fcc529baa90 =A00x00007fcc529d3334 =A0Yes (*) >> /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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dyn_ptr =3D extract_typed_add= ress (ptr_buf, >> ptr_type); >> (gdb) x ptr_addr >> 0x600ed8 >> (gdb) p ptr_buf >> $20 =3D "\000\000\000\000\000\000\000" >> Then gdb >> But when gcore didn't save the value from this section in >> "gcore_copy_callback": >> =A0/* Read-only sections are marked; we don't have to copy their content= s. >> =A0*/ >> =A0if ((bfd_get_section_flags (obfd, osec) & SEC_LOAD) =3D=3D 0) >> =A0 =A0return; >> cat /proc/7122/maps >> 00400000-00401000 r-xp 00000000 08:06 4980746 >> =A0/home/teawater/gdb/a.out >> 00600000-00601000 r--p 00000000 08:06 4980746 >> =A0/home/teawater/gdb/a.out >> 00601000-00602000 rw-p 00001000 08:06 4980746 >> =A0/home/teawater/gdb/a.out >> 7ffff7a6c000-7ffff7bd4000 r-xp 00000000 08:06 3022954 >> =A0/lib/libc-2.9.so >> 7ffff7bd4000-7ffff7dd4000 ---p 00168000 08:06 3022954 >> =A0/lib/libc-2.9.so >> 7ffff7dd4000-7ffff7dd8000 r--p 00168000 08:06 3022954 >> =A0/lib/libc-2.9.so >> 7ffff7dd8000-7ffff7dd9000 rw-p 0016c000 08:06 3022954 >> =A0/lib/libc-2.9.so >> 7ffff7dd9000-7ffff7dde000 rw-p 7ffff7dd9000 00:00 0 >> 7ffff7dde000-7ffff7dfe000 r-xp 00000000 08:06 3022858 >> =A0/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 >> =A0[vdso] >> 7ffff7ffd000-7ffff7ffe000 r--p 0001f000 08:06 3022858 >> =A0/lib/ld-2.9.so >> 7ffff7ffe000-7ffff7fff000 rw-p 00020000 08:06 3022858 >> =A0/lib/ld-2.9.so >> 7ffffffea000-7ffffffff000 rw-p 7ffffffea000 00:00 0 >> =A0[stack] >> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 >> =A0[vsyscall] >> >> >> >> I think this is the root cause of this issue. =A0Sorry guys, I use a >> long mail to show it. >> >> Do you have some comment with it? >> >> Thanks, >> Hui > > --001636e1f9953c7b120477861b31 Content-Type: text/plain; charset=US-ASCII; name="fix-gcore-lib.txt" Content-Disposition: attachment; filename="fix-gcore-lib.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g1lqr9bh0 Content-length: 655 LS0tCiBnY29yZS5jIHwgICAgNCAtLS0tCiAxIGZpbGUgY2hhbmdlZCwgNCBk ZWxldGlvbnMoLSkKCi0tLSBhL2djb3JlLmMKKysrIGIvZ2NvcmUuYwpAQCAt NTEwLDEwICs1MTAsNiBAQCBnY29yZV9jb3B5X2NhbGxiYWNrIChiZmQgKm9i ZmQsIGFzZWN0aW9uCiAgIHN0cnVjdCBjbGVhbnVwICpvbGRfY2hhaW4gPSBO VUxMOwogICB2b2lkICptZW1odW5rOwogCi0gIC8qIFJlYWQtb25seSBzZWN0 aW9ucyBhcmUgbWFya2VkOyB3ZSBkb24ndCBoYXZlIHRvIGNvcHkgdGhlaXIg Y29udGVudHMuICAqLwotICBpZiAoKGJmZF9nZXRfc2VjdGlvbl9mbGFncyAo b2JmZCwgb3NlYykgJiBTRUNfTE9BRCkgPT0gMCkKLSAgICByZXR1cm47Ci0K ICAgLyogT25seSBpbnRlcmVzdGVkIGluICJsb2FkIiBzZWN0aW9ucy4gICov CiAgIGlmIChzdHJuY21wICgibG9hZCIsIGJmZF9zZWN0aW9uX25hbWUgKG9i ZmQsIG9zZWMpLCA0KSAhPSAwKQogICAgIHJldHVybjsK --001636e1f9953c7b120477861b31--