Re: xfer_memory(..., attrib, ...) post mortem

[Fernando Nasser <fnasser@redhat.com>]

> Comments, 

Good idea!

> volunteers?

No way! :-)


Andrew Cagney wrote:
> 
> 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

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9