From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sources.redhat.com>
Subject: xfer_memory(..., attrib, ...) post mortem
Date: Wed, 21 Mar 2001 15:59:00 -0000
Message-id: <3AB064CE.91505C87@cygnus.com>
X-SW-Source: 2001-03/msg00124.html

Hello,

J.T. recently tried to modify the target vector by adding an ``attrib''
parameter to the xfer_memory() method.  Unfortunatly, a few of the
``xfer_memory()'' methods were missed (I think I've found the last of
them - patch to follow).  I figure a little P.M. is in order :-)

First however, I think I should congratulate J.T. for at least
attempting the ``right thing'' (tm)!  If you look through the sources
you'll find plenty of examples where others, when faced with that same
challenge, have just run away and hidden behind MACROs.  Just check the
TODO file:

--
Move remote_remove_hw_breakpoint, remote_insert_hw_breakpoint,
remote_remove_watchpoint, remote_insert_watchpoint into target vector.
--

So anyway, back to the P.M. - there has to be a better way.  In fact, if
we're to ever make GDB async, there had better be a better way :-)

It should be possible to modify the target vector without having to
grep/examine every line of source and potentially breaking every target.

With that in mind, I'd like to draw on the experience of
gdbarch.{sh,h.c}  and propose that the target vector be redone so that
it is more along the lines of ``struct gdbarch *''.

Doing that should make it possible for people to pull the now pretty
standard hack of, instead of changing an existing interface, introduce a
new one and rename the old to deprecated_*. A legacy function could be
used to maintain compatibility.

Comments, volunteers?

	Andrew