This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] gcore registers storing fix
- From: Michael Snyder <msnyder at vmware dot com>
- To: Daniel Gutson <dgutson at codesourcery dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Sun, 08 Nov 2009 12:03:16 -0800
- Subject: Re: [PATCH] gcore registers storing fix
- References: <4AF4A505.email@example.com>
Daniel Gutson wrote:
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.
What host configuration is this for?
At first glance, the procfs change looks ok (but I'm no longer
up to date on procfs). I have some doubt about the test change.
You say in your comment, "The threads should be standing at a
known function, rather than ??". I'm not sure how we can know
that. The threads may have been stopped anywhere, and it's
always possible to find a library with no symbols.
2009-11-06 Daniel Gutson <firstname.lastname@example.org>
* 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.
* 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.