Re: Unfinished projects

[Mark Kettenis <mark.kettenis@xs4all.nl>]

   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