From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2339 invoked by alias); 8 Oct 2004 18:48:16 -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 2312 invoked from network); 8 Oct 2004 18:48:14 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 8 Oct 2004 18:48:14 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i98ImEcI006163 for ; Fri, 8 Oct 2004 14:48:14 -0400 Received: from localhost.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 i98ImCr03925; Fri, 8 Oct 2004 14:48:13 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A3B7328D2; Fri, 8 Oct 2004 14:47:47 -0400 (EDT) Message-ID: <4166E0D3.8030607@gnu.org> Date: Fri, 08 Oct 2004 19:22:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831 MIME-Version: 1.0 To: Eli Zaretskii Cc: dk@artimi.com, brobecker@gnat.com, gdb@sources.redhat.com Subject: Re: Discussion: Formalizing the deprecation process in GDB References: <416562C9.90801@gnu.org> <01c4ad22$Blat.v2.2.2$73afa240@zahav.net.il> In-Reply-To: <01c4ad22$Blat.v2.2.2$73afa240@zahav.net.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00264.txt.bz2 >>> Date: Thu, 07 Oct 2004 11:37:45 -0400 >>> From: Andrew Cagney >>> Cc: gdb@sources.redhat.com >>> >>> A system that is being continuously re-factored is not well suited for >>> detailed internals documentation - the effort is wasted. > > > Can we say that the features that are not going to change any time > soon are sufficiently documented? For example, the CLI is not going > to be refactored any time soon (AFAIK), and yet its documentation > includes only 3 functions out of at least 10 it exports. The > completion features (I mean their GDB-specific aspects, not the > general Readline mechanism) are not documented at all. The way the current CLI code works is i18n busted. I recently deprecated several key CLI functions just to stop people adding code using them.. While there are new "draft" interfaces available they are just draft, the corresponding internals (and perhaps the interfaces) face significant change. Even the frame code isn't safe, which left the old design in the dust, is now its self reaching its limits. It's looking at a refactoring that will fundmentally change both it and the symtab. From frame has-a unwinder; to frame has-a function (is a symbol) has-a unwinder. etc, etc, etc, Andrew