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

["Ulrich Weigand" <uweigand@de.ibm.com>]

Dan,

the patch you committed to read_reg last year:
http://sourceware.org/ml/gdb-patches/2006-05/msg00089.html

in combination with the recent switch to XML register definitions,
appears to cause problems in ppc64 x ppc32 bi-arch debugging.

Specifically, when debugging a 32-bit inferior on a 64-bit
system, the DWARF-2 unwinder now sign-extends the CFA values
to 64-bit (as the stack addresses are typically in the 
0xf0000000 range, this is an actual problem).

As long as every CFA is treated the same, this is does not
really matter.  However, if there are "special" frames
(signal trampoline or dummy frames) in between, *their*
unwinders do *not* sign-extend the CFA.  This causes the
generic frame code to stop unwinding with "previous frame
inner to this frame" errors.

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.


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 guess we could change the XML definitions to force the
general purpose registers back to unsigned types, but that
doesn't seem a real solution to me.

Any suggestions how to fix this?


Thanks,
Ulrich


-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com