From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22901 invoked by alias); 14 Apr 2005 21:49:24 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 22874 invoked from network); 14 Apr 2005 21:49:20 -0000 Received: from unknown (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 14 Apr 2005 21:49:20 -0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id j3ELnBfn029294; Thu, 14 Apr 2005 23:49:11 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id j3ELnBGD022413; Thu, 14 Apr 2005 23:49:11 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id j3ELn2tr007466; Thu, 14 Apr 2005 23:49:02 +0200 (CEST) Date: Thu, 14 Apr 2005 21:49:00 -0000 Message-Id: <200504142149.j3ELn2tr007466@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: shebs@apple.com CC: gdb@sources.redhat.com In-reply-to: <425EBC8F.4030405@apple.com> (message from Stan Shebs on Thu, 14 Apr 2005 11:55:11 -0700) Subject: Re: Unfinished projects References: <425EBC8F.4030405@apple.com> X-SW-Source: 2005-04/txt/msg00081.txt.bz2 Date: Thu, 14 Apr 2005 11:55:11 -0700 From: Stan Shebs 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