Re: dwarf2-frame.c read_reg problems, again ...

[Daniel Jacobowitz <drow@false.org>]

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