From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: GDB Discussion Subject: Re: xfer_memory(..., attrib, ...) post mortem Date: Wed, 21 Mar 2001 15:59:00 -0000 Message-id: <5mitl47zxo.fsf@jtc.redback.com> References: <3AB064CE.91505C87@cygnus.com> X-SW-Source: 2001-03/msg00210.html >>>>> "Andrew" == Andrew Cagney writes: Andrew> It should be possible to modify the target vector without Andrew> having to grep/examine every line of source and potentially Andrew> breaking every target. Andrew> Andrew> With that in mind, I'd like to draw on the experience of Andrew> gdbarch.{sh,h.c} and propose that the target vector be redone Andrew> so that it is more along the lines of ``struct gdbarch *''. Andrew> Andrew> Doing that should make it possible for people to pull the now Andrew> pretty standard hack of, instead of changing an existing Andrew> interface, introduce a new one and rename the old to Andrew> deprecated_*. A legacy function could be used to maintain Andrew> compatibility. Andrew Andrew> Comments, [...] I want to point out that it is possible to take backwards compatibility too far. Experience has told me that when you have a "flag day" conversion, there is a little pain as loose ends are cleaned up, but then it's over and down with. But if backwards compatible interfaces are maintained, chances are good that nothing will be done. There is no incentive for change. In the end, the system is saddled with the complexity of multiple implementations. That's why I approve (in principle) of the discussion to remove the sync event loop even though it will likely break my remote-wdb.c back end. If anything, I think that we haven't been aggressive enough wrt. flushing these from GDB. e.g. changing FRAME_FIND_SAVED_REGS to FRAME_INIT_SAVED_REGS is a reasonably easy change, but many ports have yet to make the switch. In short, I have no problems with global changes with unforseen rough edges that get cleaned up in a few days for actively maintained targets, and perhaps a bit longer for those targets that aren't. I believe this results in better code in the long term, and the occasional pain isn't great enough to outweigh this. --jtc -- J.T. Conklin RedBack Networks