Re: Unfinished projects

[Russell Shaw <rjshaw@netspace.net.au>]

Mark Kettenis wrote:
>    Date: Thu, 14 Apr 2005 11:55:11 -0700
>    From: Stan Shebs <shebs@apple.com>
> 
>    Andrew's sudden departure from GDB maintenance seems to left a
>    large number of projects in mid-process; as I'm picking through
>    the latest sources trying to figure out how to merge with Apple's
>    bits, it's very confusing as to how the new way is supposed to
>    work when it's not documented anywhere and there's maybe only
>    one example of a configuration using it.
> 
>    So my question is - what should we do about all these? Are
>    some of these intrinsically impossible to complete without
>    the right collection of hardware? If so, then maybe we need
>    to get tougher about dropping support for some targets, or
>    else abandon the projected change. I'd like to work on updating
>    the GDB internals manual too, for my own understanding if
>    nothing else; should I describe old ways, new ways, or both?
> 
> If anything, only document the new way.  Out of the top of my head I
> don't know any newly introduced mechanisms that really have been
> abandoned.  But indeed there are many mechanisms that have not been
> adapted by all targets.
> 
> The problem is that we have many targets for which there is not a
> maintainer, and some targets for which the maintainer has been "lazy".
> We have never really made it the responsibility of the maintainers to
> update their targets to use the new ways of doing this, and I think we
> should.
> 
> That said, I don't really consider documenting the mechanisms a big
> priority.  I think a set of targets that use the proper mechanisms is
> much more important.  I usually don't completely get how things are
> supposed to work until I see some good code that uses a particular
> mechanism.  But because we have many targets that still use the
> outdated hacks it isn't always obvious what the proper mechanisms are.
> To make matters worse, I think the most "obvious" code to look isn't
> always the best code to look at to understand how things are supposed
> to work; in some respects this is particularly true for Linux/i386.
> 
> Of the targets I'm familliar with, these targets are basically clean:
> 
> * sparc/sparc64, m88k, vax, i386/amd64
> 
> These are mostly clean, but still need some work:
> 
> * m68k, powerpc, mips/mips64, alpha
> 
> And these still need a serious amount of work:
> 
> * arm, hppa, ia64
> 
> On the native support side things are a bit more murky.  The *BSD
> natives mostly use up-to-date mechanisms, but the Linux world is in
> quite a bit of disarray.  The problem here is that Linux native
> support is scattered over many people and a ridiculous number of Linux
> targets is basically unmaintained.  We really need someone with an
> overview to work on making the Linux stuff more uniform.
> 
> Then of course there is the embedded side of things.  Here there is a
> tendency of companies contributing support for their own chip with
> their own remote protocol and then abandoning it.  There seems to be
> almost no interest for folks to work on the common infrastructure for
> debugging embedded stuff.  This leaves us with quite a bit of cruft.
> 
> But the most serious problem is the fact that development of out
> symbol readers has basically stopped.  The round-trip for having
> patches reviewed in this area is in the order of weeks, and this is
> not encouraging other people to work on it (to use an understatement).
> 
> Feel free to nominate targets for removal; there probably still is
> quite a bit of dead wood in our tree.
> 
> Mark
> 

I'd create a new gdb copy that only has the maintained stuff in it, so it
can all be easily cleaned up. Then if someone needs one of the unmaintained
targets, they can use the old gdb, or port that stuff from the old gdb to
the new gdb.