This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: xfer_memory(..., attrib, ...) post mortem
- To: jtc at redback dot com
- Subject: Re: xfer_memory(..., attrib, ...) post mortem
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 21 Mar 2001 10:57:30 -0500
- Cc: GDB Discussion <gdb at sources dot redhat dot com>
- References: <3AB064CE.91505C87@cygnus.com> <5mitl47zxo.fsf@jtc.redback.com>
"J.T. Conklin" wrote:
> 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.
Depends on what you mean by ``flag day''.
I can see the following ongoing process occuring:
o new interfaces being introduced
(see gdbarch_register_{read,write})
o redundant interfaces (from above)
being deprecated or deleted
o targets that are full of deprecated
code being obsoleted.
The emphasis being on a continuum of change rather than single ``flag
days''. That way, at any stage, GDB should still be working and
stable. I could, in theory, cut a new GDB release at any time - the
project shouldn't be able to go down the rat hole of wildly osolating
between radical new development and stablizing for the next release.
However, I do see something very similar to a ``flag day'' looming. A
line needs to be draw in the sand after which point any target (read x86
and arm) that isn't using gdbarch will be obsoleted.
That line should probably be called ``5.2''.
> 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.
I'm expecting to see the following process:
o a new interface being introduced
o where applicable legacy code
for the previous interface being
provided.
o that new interface evolve and
stablize.
This is important, it allows the
new interface to stablize without
the need to constantly change all
the existing targets.
o the old/redundant interfaces be
deprecated and/or that code be updated
This is probably where GDB has
been falling down. I intend
being really agressive with
applying the mechanical operation
s/interface/deprecated_interface/.
As an example, consider the gdbarch_register_{read,write} and associated
changes. I wouldn't expect existing code to rush out and use this now.
Rather, I'd expect people maintaining existing targets to wait a little
and then leap frog the current interface going straght to what is
hopefully the final version.
Any way, in the end it is a balancing act between keeping GDB stable and
allowing new development :-)
Andrew