From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1332 invoked by alias); 14 Apr 2005 19:01:32 -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 1306 invoked from network); 14 Apr 2005 19:01:24 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 14 Apr 2005 19:01:24 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DM9ad-0004hc-Qf; Thu, 14 Apr 2005 15:01:23 -0400 Date: Thu, 14 Apr 2005 19:01:00 -0000 From: Daniel Jacobowitz To: Stan Shebs Cc: gdb@sources.redhat.com Subject: Re: Unfinished projects Message-ID: <20050414190123.GA18019@nevyn.them.org> Mail-Followup-To: Stan Shebs , gdb@sources.redhat.com References: <425EBC8F.4030405@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425EBC8F.4030405@apple.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-04/txt/msg00077.txt.bz2 On Thu, Apr 14, 2005 at 11:55:11AM -0700, Stan Shebs wrote: > 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? Could you give some specific examples that you're looking at? I've got no way to answer your questions without more details. For each one, there's probably someone on the list who knows how it's supposed to work. Converting that knowledge into better internals documentation would, obviously, be great. -- Daniel Jacobowitz CodeSourcery, LLC