From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5580 invoked by alias); 28 Jun 2004 21:45:18 -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 5512 invoked from network); 28 Jun 2004 21:45:16 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 28 Jun 2004 21:45:16 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i5SLjFe1007597 for ; Mon, 28 Jun 2004 17:45:15 -0400 Received: from zenia.home.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i5SLjD013136; Mon, 28 Jun 2004 17:45:14 -0400 To: Andrew Cagney Cc: Michael Elizabeth Chastain , gdb@sources.redhat.com Subject: Re: Technical criteria for retaining symbol readers References: <20040623195109.E8A974B104@berman.michael-chastain.com> <40D9E494.6030405@gnu.org> From: Jim Blandy Date: Mon, 28 Jun 2004 23:59:00 -0000 In-Reply-To: <40D9E494.6030405@gnu.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-06/txt/msg00280.txt.bz2 Andrew Cagney writes: > > jimb> I'd also like to have some kind of requirement for testability. > > I would, too. My preference would be that we look at gdb-testers@ > > and if there are no test results for feature X for the past N years, > > that counts against keeping feature X. gcc uses that as one factor > > in deciding whether to obsolete stuff. > > That's been suggested in the past. It was pointed out that some > systems can't run the testsuite (DJGPP) so on its own it wasn't > reasonable (neither is assuming that the presence of test results > stops an architecture being removed :-). DJGPP (go32-nat.c) doesn't use deprecated interfaces, so it's not a maintenance burden in core GDB work. If a target or host has been kept up to date as interfaces have been deprecated, I'm not sure we should consider removing it --- obviously somebody cares about it, and cares in the way that matters. An absence of test results, plus the use of deprecated interfaces that most other targets have moved beyond, seems like sufficient reason to ditch something. As far as the symtab stuff goes, we don't (yet) have deprecated interfaces to the symtab core, so that criterion doesn't help us there. Looking through the interfaces actually in use and beginning a deprecation process is called for there.