Re: D10V_MAKE_IADDR / D10V_MAKE_DADDR / GDB_TARGET_IS_D10V

[Andrew Cagney <ac131313 at cygnus dot com>]

David Taylor wrote:
> 
> I'd like to change the names
> 
>     D10V_MAKE_IADDR
>     D10V_MAKE_DADDR
>     GDB_TARGET_IS_D10V
> 
> to something more meaningful...
> 
> [I am currently working on a port which will need all three!  Or, to
> put it another way, it will need very similar changes -- for similar
> reasons as the d10v -- in the same places...]
> 
> D10V_MAKE_IADDR and D10V_MAKE_DADDR convert text and data addresses
> respectively from target representation to gdb representation.
> 
> And GDB_TARGET_IS_D10V just seems to determine whether or not some
> code containing calls to the D10V_MAKE_[ID]ADDR routines gets
> executed or not.

Yes.  The reason the D10V stuff was tolerated was because it identified
all the places there were problems.

> For names, how about:
> 
>     CONVERT_IADDR_FROM_TARGET
>     CONVERT_DADDR_FROM_TARGET
>     ADDRESSES_NEED_CONVERSION_P

The names don't worry me.

> Comments?

In theory the ADDRESS_TO_POINTER() and POINTER_TO_ADDRESS() macro's are
ment to address (groan) the problems identified by the D10V_MAKE* macros
and should make them obsolete.

I've still to go back through the d10v code and confirm this.

To be honest, I have a feeling that the ADDRESS_TO_POINTER() macro's may
not be sufficient as I don't know how well it will handle pure harvard
architectures where address/data pointers are very different.  If
nothing else, the ``builtin_type_ptr'' would need to be expanded into
``builtin_type_{func,data}_ptr''.

	Andrew