Re: [RFA/RFC] dwarf2-frame read_reg

[Michael Snyder <msnyder@redhat.com>]

Daniel Jacobowitz wrote:
> On Wed, Apr 12, 2006 at 08:17:07PM +0200, Mark Kettenis wrote:
> 
>>>Date: Tue, 11 Apr 2006 21:42:01 -0700
>>>From: "Jim Blandy" <jimb@red-bean.com>
>>>
>>>On 4/11/06, Michael Snyder <msnyder@redhat.com> wrote:
>>>
>>>>I want you guys to vett this change.  I was getting wrong results
>>>>on a target where sizeof (SP) != sizeof (void *).  The local func
>>>>read_reg was calling extract_unsigned_integer with the wrong size.
>>>
>>>Well, extract_typed_address requires the type of the register to be
>>>some sort of pointer.  read_reg is given as a callback to the Dwarf
>>>expression evaluator in dwarf2expr.c, so it could be handed any
>>>register at all.
>>>
>>>How about unpack_long (buf, register_type (gdbarch, regnum))? 
>>>Definitely regression-test this on several platforms...
>>
>>This is likely to be wrong for platforms where addresses are signed.
> 
> 
> It shouldn't be.
> 
> unpack_long (struct type *type, const gdb_byte *valaddr)
> {
> ...
>     case TYPE_CODE_PTR:
>     case TYPE_CODE_REF:
>       /* Assume a CORE_ADDR can fit in a LONGEST (for now).  Not sure
>          whether we want this to be true eventually.  */
>       return extract_typed_address (valaddr, type);
> 
> which calls POINTER_TO_ADDRESS.  And that will be the signed unpack for
> MIPS, and the unsigned unpack for other targets.
> 
> So I think unpack_long is a good choice.
> 
> (I didn't realize that before.  I think I have another pending patch
> that this would be useful for - maybe the psaddr_t one?)

May I release the patch into your care?  I don't really think
I understand the problem domain well enough (wouldn't be able
to test it well), and I've made my own need for it go away by
other means.