This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: INTEGER_TO_ADDRESS(), thoughts?
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: INTEGER_TO_ADDRESS(), thoughts?
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 20 Sep 2001 21:23:52 -0400
- Cc: gdb at sources dot redhat dot com
- References: <3BA7F150.9060302@cygnus.com>
> I'd like to propose a cleanup to this:
>
> /* Some architectures (e.g. Harvard), map instruction and data
> addresses onto a single large unified address space. For
> instance: An architecture may consider a large integer in the
> range 0x10000000 .. 0x1000ffff to already represent a data
> addresses (hence not need a pointer to address conversion) while
> a small integer would still need to be converted integer to
> pointer to address. Just assume such architectures handle all
> integer conversions in a single function. */
>
> if (TYPE_CODE (VALUE_TYPE (val)) == TYPE_CODE_INT
> && INTEGER_TO_ADDRESS_P ())
> return INTEGER_TO_ADDRESS (VALUE_TYPE (val), VALUE_CONTENTS (val));
> Assuming it soulds ok, I can knock up a patch + doco changes.
In knocking up the patch I thought of an iteresting edge condition.
What should:
x/i 1.0
do? I'd guess 1.0 -> 1 -> (void*)1. One way of handling this would be
to adjust the code so that it reads:
if (type_code (...) != type_code_ptr)
&& integer_to_address_p()
return ...
That way, the target architecture gets to prod anything that isn't
already an address. For the ``x/i 1.0'' i'd expect it to be converted
into an integer and then into an address.
However, I think it might be easier if we simply throw the problem back
at the architecture vis
if (value_to_address_p())
return value_to_address (...);
return unpack_long (...);
Andrew