This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: D10V_MAKE_IADDR / D10V_MAKE_DADDR / GDB_TARGET_IS_D10V
- To: David Taylor <taylor at cygnus dot com>
- Subject: Re: D10V_MAKE_IADDR / D10V_MAKE_DADDR / GDB_TARGET_IS_D10V
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Mon, 24 Jul 2000 15:08:04 +1000
- CC: gdb-patches at sourceware dot cygnus dot com
- References: <200007212021.QAA03204@texas.cygnus.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