This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: INTEGER_TO_ADDRESS(), thoughts?


> 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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]