This is the mail archive of the
gdb-cvs@sourceware.org
mailing list for the GDB project.
gdb and binutils branch master updated. 7ce16bd4c4d5e6f6a48ca7fcf532720fec0406bf
- From: uweigand at sourceware dot org
- To: gdb-cvs at sourceware dot org
- Date: 17 Apr 2014 12:13:38 -0000
- Subject: gdb and binutils branch master updated. 7ce16bd4c4d5e6f6a48ca7fcf532720fec0406bf
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".
The branch, master has been updated
via 7ce16bd4c4d5e6f6a48ca7fcf532720fec0406bf (commit)
via 2ed3c037cf8aac5f6dbee5b6c2a1239550a04202 (commit)
from 40d1a503c43cda6c04a637972e5635d803f46cde (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7ce16bd4c4d5e6f6a48ca7fcf532720fec0406bf
commit 7ce16bd4c4d5e6f6a48ca7fcf532720fec0406bf
Author: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Date: Thu Apr 17 14:09:49 2014 +0200
Enable DWARF unwinders for SPU
This patch enables use of DWARF unwinders for the SPU target.
In addition to appending the DWARF unwinders, we also need to install
a spu_dwarf_reg_to_regnum that maps the raw stack pointer register to
the cooked version (to avoid mismatches with gdbarch_sp_regnum).
This also causes confusion with the AX collect handling, so we also
install ax_pseudo_register routines to handle the cooked SP.
gdb/
2014-04-17 Ulrich Weigand <uweigand@de.ibm.com>
* spu-tdep.c: Include "dwarf2-frame.h" and "ax.h".
(spu_ax_pseudo_register_collect): New function.
(spu_ax_pseudo_register_push_stack): Likewise.
(spu_dwarf_reg_to_regnum): Likewise.
(spu_gdbarch_init): Install them. Append DWARF unwinders.
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2ed3c037cf8aac5f6dbee5b6c2a1239550a04202
commit 2ed3c037cf8aac5f6dbee5b6c2a1239550a04202
Author: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Date: Thu Apr 17 14:01:39 2014 +0200
Use address_from_register in dwarf2-frame.c:read_addr_from_reg
This patch fixes a problem that prevented use of the Dwarf unwinders on SPU,
because dwarf2-frame.c common code did not support the situation where the
stack and/or frame pointer is maintained in a *vector* register. This is
because read_addr_from_reg is hard-coded to assume that such pointers can
be read from registers via a simple get_frame_register / unpack_pointer
operation.
Now, there *is* a routine address_from_register that calls into the
appropriate tdep routines to handle pointer values in "weird" registers
like on SPU, but it turns out I cannot simply change dwarf2-frame.c to
use address_from_register. This is because address_from_register uses
value_from_register to create a (temporary) value, and that routine
at some point calls get_frame_id in order to set up that value's
VALUE_FRAME_ID entry.
However, the dwarf2-frame.c read_addr_from_reg routine will be called
during early unwinding (to unwind the frame's CFA), at which point the
frame's ID is not actually known yet! This would cause an assert.
On the other hand, we may notice that VALUE_FRAME_ID is only needed in the
value returned by value_from_register if that value is later used as an
lvalue. But this is obviously never done to the temporary value used in
address_from_register. So, if we could change address_from_register to
not call value_from_register but instead accept constructing a value
that doesn't have VALUE_FRAME_ID set, things should be fine.
To do that, we can change the value_from_register callback to accept
a FRAME_ID instead of a FRAME; the only existing uses of the FRAME
argument were either to extract its frame ID, or its gdbarch. (To
keep a way of getting at the latter, we also change the callback's
type from "f" to "m".) Together with the required follow-on changes
in the existing value_from_register implementations (including the
default one), this seems to fix the problem.
As another minor interface cleanup, I've removed the explicit TYPE
argument from address_from_register. This routine really always
uses a default pointer type, and in the new implementation it -to
some extent- relies on that fact, in that it will now no longer
handle types that require gdbarch_convert_register_p handling.
gdb:
2014-04-17 Ulrich Weigand <uweigand@de.ibm.com>
* gdbarch.sh (value_from_register): Make class "m" instead of "f".
Replace FRAME argument with FRAME_ID.
* gdbarch.c, gdbarch.h: Regenerate.
* findvar.c (default_value_from_register): Add GDBARCH argument;
replace FRAME by FRAME_ID. No longer call get_frame_id.
(value_from_register): Update call to gdbarch_value_from_register.
* value.h (default_value_from_register): Update prototype.
* s390-linux-tdep.c (s390_value_from_register): Update interface
and call to default_value_from_register.
* spu-tdep.c (spu_value_from_register): Likewise.
* findvar.c (address_from_register): Remove TYPE argument.
Do not call value_from_register; use gdbarch_value_from_register
with null_frame_id instead.
* value.h (address_from_register): Update prototype.
* dwarf2-frame.c (read_addr_from_reg): Use address_from_register.
* dwarf2loc.c (dwarf_expr_read_addr_from_reg): Update for
address_from_register interface change.
-----------------------------------------------------------------------
Summary of changes:
gdb/ChangeLog | 29 ++++++++++++++++++++
gdb/dwarf2-frame.c | 10 +-----
gdb/dwarf2loc.c | 8 +----
gdb/findvar.c | 34 ++++++++++++++++--------
gdb/gdbarch.c | 4 +-
gdb/gdbarch.h | 6 ++--
gdb/gdbarch.sh | 4 +-
gdb/s390-linux-tdep.c | 8 +++---
gdb/spu-tdep.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++--
gdb/value.h | 7 +++--
10 files changed, 137 insertions(+), 42 deletions(-)
hooks/post-receive
--
gdb and binutils