From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Andrew Cagney Cc: GDB Discussion Subject: Re: xfer_memory(..., attrib, ...) post mortem Date: Wed, 21 Mar 2001 15:59:00 -0000 Message-id: <3AB0DBB9.9E9789C5@redhat.com> References: <3AB064CE.91505C87@cygnus.com> X-SW-Source: 2001-03/msg00125.html > 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