From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23276 invoked by alias); 17 Dec 2006 15:37:36 -0000 Received: (qmail 23265 invoked by uid 22791); 17 Dec 2006 15:37:36 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sun, 17 Dec 2006 15:37:30 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1Gvy4s-0004MT-9M; Sun, 17 Dec 2006 10:37:26 -0500 Date: Sun, 17 Dec 2006 15:37:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb@sourceware.org, dave.anglin@nrc-cnrc.gc.ca, brobecker@adacore.com, Mark Kettenis Subject: Re: Likely obsolete pieces of GDB Message-ID: <20061217153726.GB16423@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb@sourceware.org, dave.anglin@nrc-cnrc.gc.ca, brobecker@adacore.com, Mark Kettenis References: <20061216205923.GA21428@nevyn.them.org> <13057.82.92.89.47.1166358029.squirrel@webmail.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13057.82.92.89.47.1166358029.squirrel@webmail.xs4all.nl> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00161.txt.bz2 Thanks to everyone who replied! I'll collect all the feedback and revise the list - either next week or after I get back from my holiday vacation. On Sun, Dec 17, 2006 at 01:20:29PM +0100, Mark Kettenis wrote: > Yes, it is time for these to go. The main reason they're still there is > because our current procedure for obsoleting targets is too complicated > and too ugly. I really can't get myself to put OBSOLETE on every line of > the affected source files. Can we change the policy to something like > what the GCC people do? They put a stanza in config.gcc that lists the > obsolete configs and bails out on those configs unless the user > specifies --enable-obsolete. Then the config gets removed completely > after the next release. > > That said, I don't really have a problem with zapping these now. I am happy to change the mechanism; I don't like // OBSOLETE either. We can't even use the current mechanism for some of these files: anything not directly corresponding to a target. To be honest, I'd been thinking about waiting for everyone to agree on which things to remove, sending a message to gdb-announce, and then just doing it. If there were any justifiable complaints at the time of the next release we could recover targets from CVS history. I'm sure not everyone is comfortable with that sudden of an approach, so using configure for targets for one release is fine with me too. > > mdebugread.c > > mdebugread.h > > > > If there's any platform left that still produces this format > > of symbolic debug information, I don't know what it is. > > I think these are still necessary for Alpha (alpha-mdebug-tdep.c). This is the only file I've seen any objections to that I really wanted to get rid of, but it looks like you're right. Do you know which Alpha configurations are likely to use it, so that we can know when we don't need it any more? Maybe it's all the ECOFF ones. -- Daniel Jacobowitz CodeSourcery