This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: dwarf2-frame.c read_reg problems, again ...
- From: Daniel Jacobowitz <drow at false dot org>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 30 Oct 2007 22:18:21 -0400
- Subject: Re: dwarf2-frame.c read_reg problems, again ...
- References: <200710310151.l9V1pTLb008147@d12av02.megacenter.de.ibm.com>
On Wed, Oct 31, 2007 at 02:51:29AM +0100, Ulrich Weigand wrote:
> With the patch refered to above, read_reg will respect the
> signedness of the register_type, if it is an integral type.
> This is not a problem if the register type is a pointer type
> (in which case pointer_to_address would be consulted), but
> on ppc the CFA gets computed from regular general purpose
> registers, with an integral register_type.
>
> Those in turn used to be described as "builtin_type_uint32"
> by the original rs6000_register_type. The generic XML-based
> machinery now apparently uses a signed integer type instead,
> exposing the problem.
This was plainly and simply a mistake. While I agree that changing
them back is not a real solution to the problem you've found, I didn't
mean to flip the signedness of all those registers. If uint32 is in
any sense more architecturally appropriate, or even for sheer
tradition, let's flip them back.
> Now I'm wondering: what was the motivation behind using
> unpack_long here? The dwarf2loc.c:dwarf_expr_read_reg
> routine, which saves basically the same purpose, now uses
> address_from_register -- i.e. specifically treats the
> value as pointer, not integer ...
I think we have about five too many ways to take a register and make
it into a number. On the other hand, dwarf_expr_read_reg
uses builtin_type_void_data_ptr. That is probably broken on
whatever target Michael Snyder was trying to fix in the patch
you referenced, where the sizes differ.
If we use address_from_register, we will end up in a call to
unpack_long using the provided type. So I think that is exactly the
same as what we have now.
This is the trouble with using a host integer type to represent target
addresses. If we did all our arithmetic on opaque CORE_ADDR's, this
wouldn't happen. I wonder if there's no getting around the need to
define a sensible calculus for them...
--
Daniel Jacobowitz
CodeSourcery