From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31849 invoked by alias); 6 Nov 2009 22:37:11 -0000 Received: (qmail 31831 invoked by uid 22791); 6 Nov 2009 22:37:10 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Nov 2009 22:37:05 +0000 Received: (qmail 11758 invoked from network); 6 Nov 2009 22:37:03 -0000 Received: from unknown (HELO ?192.168.9.129?) (daniel@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Nov 2009 22:37:03 -0000 Message-ID: <4AF4A505.4010600@codesourcery.com> Date: Fri, 06 Nov 2009 22:37:00 -0000 From: Daniel Gutson User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: [PATCH] gcore registers storing fix Content-Type: multipart/mixed; boundary="------------090402040802070509050907" Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-11/txt/msg00120.txt.bz2 This is a multi-part message in MIME format. --------------090402040802070509050907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1019 The attached patch attempts to solve a bug that caused the gcore command to produce core files containing incorrect registers information. The problem caused incomplete backtraces when the files were read back into GDB. I tested this patch with the gdb testsuite, and my addition to the gcore-thread.exp test case. If OK, please commit it for me since I don't have write access. Thanks, Daniel. 2009-11-06 Daniel Gutson gdb/ * procfs.c (procfs_do_thread_registers): Added a call to fetch register values before saving them in the core file through the gcore command. (procfs_corefile_thread_callback): removed the backup of inferior_ptid before calling procfs_do_thread_registers since the function already saves and restores it before returning. gdb/testsuite/gdb.threads/ * gcore-thread.exp: Added a test case in order to check if the core dump contains the registers values, and symbol lookup is working properly. -- Daniel Gutson CodeSourcery www.codesourcery.com --------------090402040802070509050907 Content-Type: text/x-diff; name="gcore.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gcore.patch" Content-length: 3163 Index: gdb/procfs.c =================================================================== RCS file: /cvs/src/src/gdb/procfs.c,v retrieving revision 1.119 diff -u -p -r1.119 procfs.c --- gdb/procfs.c 21 Oct 2009 08:27:25 -0000 1.119 +++ gdb/procfs.c 6 Nov 2009 22:30:54 -0000 @@ -6060,9 +6060,19 @@ procfs_do_thread_registers (bfd *obfd, p gdb_gregset_t gregs; gdb_fpregset_t fpregs; unsigned long merged_pid; + struct cleanup *old_chain; merged_pid = TIDGET (ptid) << 16 | PIDGET (ptid); + /* This part is the old method for fetching registers. + It should be replaced by the newer one using regsets + once it is implemented in this platform: + gdbarch_regset_from_core_section() and regset->collect_regset(). */ + + old_chain = save_inferior_ptid (); + inferior_ptid = ptid; + target_fetch_registers (regcache, -1); + fill_gregset (regcache, &gregs, -1); #if defined (UNIXWARE) note_data = (char *) elfcore_write_lwpstatus (obfd, @@ -6085,6 +6095,9 @@ procfs_do_thread_registers (bfd *obfd, p note_size, &fpregs, sizeof (fpregs)); + + do_cleanups (old_chain); + return note_data; } @@ -6102,13 +6115,11 @@ procfs_corefile_thread_callback (procinf if (pi != NULL) { - ptid_t saved_ptid = inferior_ptid; - inferior_ptid = MERGEPID (pi->pid, thread->tid); - args->note_data = procfs_do_thread_registers (args->obfd, inferior_ptid, + ptid_t ptid = MERGEPID (pi->pid, thread->tid); + args->note_data = procfs_do_thread_registers (args->obfd, ptid, args->note_data, args->note_size, args->stop_signal); - inferior_ptid = saved_ptid; } return 0; } Index: gdb/testsuite/gdb.threads/gcore-thread.exp =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/gcore-thread.exp,v retrieving revision 1.13 diff -u -p -r1.13 gcore-thread.exp --- gdb/testsuite/gdb.threads/gcore-thread.exp 3 Jan 2009 05:58:07 -0000 1.13 +++ gdb/testsuite/gdb.threads/gcore-thread.exp 6 Nov 2009 22:30:54 -0000 @@ -154,11 +154,7 @@ gdb_expect { } } -# FIXME: now what can we test about the thread state? -# We do not know for certain that there should be at least -# three threads, because who knows what kind of many-to-one -# mapping various OS's may do? Let's assume that there must -# be at least two threads: +# There must be at least two threads. gdb_test "info threads" ".*${nl} 2 ${horiz}${nl}\\* 1 .*" \ "corefile contains at least two threads" @@ -173,3 +169,16 @@ gdb_test "info threads" ".* thread2 .*" gdb_test "info threads" ".*${nl}\\* ${horiz} thread2 .*" \ "thread2 is current thread in corefile" +# The threads should be standing at a known function, rather than ??. + +gdb_test_multiple "info threads" \ + "corefile contains good register values and enables symbols lookup" \ +{ + -re ".* in \\?\\? .*" { + fail "corefile contains good register values and enables symbols lookup" + } + -re ".* in \[_a-zA-Z0-9]+ \\(.*" { + pass "corefile contains good register values and enables symbols lookup" + } +} + --------------090402040802070509050907--