Re: [RFC] dwarf2_read_address(): sign extend as appropriate

[Kevin Buettner <kevinb@redhat.com>]

On Tue, 24 Apr 2007 00:43:05 +0200
Andreas Schwab <schwab@suse.de> wrote:

> Daniel Jacobowitz <drow@false.org> writes:
> 
> > On Mon, Apr 23, 2007 at 09:49:00AM -0700, Kevin Buettner wrote:
> >> We can't use address_from_register() in this instance since
> >> dwarf2_read_address() is not fetching an address from a register, but
> >> rather from some DWARF2 info.
> >
> > How about value_as_address?
> 
> How about extract_typed_address?

I really liked this suggestion when I first saw it because it appears
that it would do the right thing on MIPS and we would avoid creating a
value which we'd immediately take apart again.

However, after further study, I see two issues with using this function:

    1) extract_typed_address() does its conversion using
       POINTER_TO_ADDRESS.  For most architectures, this isn't
       an issue, but I'm not convinced that it will work correctly
       for those which define non-trivial pointer-to-address methods. 

    2) dwarf2_read_address is currently extracting an address which
       is TARGET_ADDR_BIT bits wide.  extract_typed_address() must be
       invoked on a pointer (TYPE_CODE_PTR) or reference (TYPE_CODE_REF)
       type.  If it gets anything else, it generates an internal error.
       If the pointer type passed to extract_typed_address() is created
       via make_pointer_type(), the type width will be TARGET_PTR_BIT
       rather than TARGET_ADDR_BIT.  Thus, I'd expect extract_typed_address()
       to work as expected on architectures for which TARGET_ADDR_BIT
       is the same as TARGET_PTR_BIT, but not otherwise - unless some
       sort of special TARGET_ADDR_BIT width pointer were created for
       just this purpose - but that smells like a hack to me.

Given these problems, I don't think that the use of
extract_typed_address() is suitable for this situation.

That leaves the value_as_address() suggestion.  I don't like that
suggestion, but my only objection is that it is inefficient.  (As far
as I can tell, it would work correctly.)  It seems wasteful (in both
time and space) to create a (struct value *) with the express purpose
of immediately decomposing it, never to be used again.

Kevin