From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6960 invoked by alias); 7 Oct 2004 15:38: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 6946 invoked from network); 7 Oct 2004 15:38:16 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 7 Oct 2004 15:38:16 -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 i97FcBkE002870 for ; Thu, 7 Oct 2004 11:38:11 -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 i97Fc9r22993; Thu, 7 Oct 2004 11:38:10 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id F356F28D2; Thu, 7 Oct 2004 11:37:45 -0400 (EDT) Message-ID: <416562C9.90801@gnu.org> Date: Thu, 07 Oct 2004 16:14: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: Dave Korn , "'Joel Brobecker'" , "'Eli Zaretskii'" Cc: gdb@sources.redhat.com Subject: Re: Discussion: Formalizing the deprecation process in GDB References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00218.txt.bz2 > Ok, I also read the code, but I very much appreciate having good > documentation in book format. If you've got a serious chunk of architecture > to learn about, it's a lot easier if it's all in one file that you can print > out and browse through at your leisure rather than a page here and a page > there scattered across many files. (An architecture document is no more than 2 A4 pages, and one diagram - that is extreemly highlevel but gets across the concepts.) > FWIW I reckon gcc is getting it very right these days. There's a > heavyweight internals manual that explains the architecture and big picture > issues. Each file that implements a substantial module of functionality > then also has documentation about its internals and implementation at the > top of the file. Usually you only need the internals manual, and only if > you find yourself rummaging around in the depths of alias analysis or > something chasing a bug do you find yourself needing the per-file-internal > documentation. Yes, it's useful to understand why this is. GCC has a simple pipeline architecture --. It's details can be described at two levels: the interfaces between each "end" (ssa / rtl?); and the internals of a specific "end" (this implements algorithm X). GDB doesn't have that luxury. It's internals model the state of a running program using objects and their interactions. In such a system it is the complex relationships between the objects that is important, and not the details of a specific bit of code. For GCC typically a new "end" (or pass) can simply be plugged in, or an existing "end" rewritten. For GDB, fixing the hard problems involves making changes to those complex object relationships and such requires significant and regular refactoring. A system that is being continuously re-factored is not well suited for detailed internals documentation - the effort is wasted. Instead the high level architecture and medium level object models that are important. > Since opinions are being invited, I'll just mention that I'm currently > working on an internal version of gdb for which I'm having to up-port a > 5.x-compatible backend to 6.x series. I sometimes find it *ever* so hard > when faced with yet another deprecated__ this or obsoleted_ that to know > what the new and approved replacement is, and it often takes a combination > of the internals manual, the in-source documentation and comments, and much > searching of the list archive for the actual patch that made the deprecation > to see how it was done at the time and understand the background and > reasoning to it. I understand the reasons for using this technique and > agree that it's sound engineering practice and necessary for the onward > development of gdb, but I would like an easier solution to the general > problem of knowing what to replace something with, and one that could be > used off-line or on those occasions when sourceware goes down and you can't > get at the list archive! For multi-arch I wrote a migration document. This time I did not. There is no "migration" path. The correct approach is: - delete all deprecated code - build - run testsuite - add a missing architecture vector method - repeat Instead of migrating, trying to reproduce each refactoring step, you should leap frog. A running joke between several of the GDB developers at the last GCC summit was that we should present a 1hr paper titled "porting GDB to a new architecture". Only instead of presenting slides, we'd just write the code. Andrew