This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] dwarf2_read_address(): sign extend as appropriate
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