From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10912 invoked by alias); 7 Oct 2004 17:20:07 -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 10840 invoked from network); 7 Oct 2004 17:20:02 -0000 Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177) by sourceware.org with SMTP; 7 Oct 2004 17:20:02 -0000 Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 18:19:40 +0100 From: "Dave Korn" To: "'Andrew Cagney'" , "'Joel Brobecker'" , "'Eli Zaretskii'" Cc: Subject: RE: Discussion: Formalizing the deprecation process in GDB Date: Thu, 07 Oct 2004 18:08:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <416562C9.90801@gnu.org> Message-ID: X-OriginalArrivalTime: 07 Oct 2004 17:19:40.0611 (UTC) FILETIME=[D459D930:01C4AC91] X-SW-Source: 2004-10/txt/msg00226.txt.bz2 > -----Original Message----- > From: Andrew Cagney > Sent: 07 October 2004 16:38 > > 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.) Um, OK, that wasn't the kind of document I was talking about. I was thinking of something more like (frex) the set of manuals that describe and specify the abstract PPC operating environment (without reference to any specific ppc cpu implementation). > 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. This is something more like what I meant to describe by the term "chunk of architecture". Or something like (to use another gcc example) rtl and the chapter on rtl in the gccint manual. As you say, high-to-mid range overview. Design decisions, system architecture, but not low-level implementation specifics. > 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. I'm not trying to migrate; I haven't been trying to get a stable working version and make incremental changes that recapitulate the history of gdb's recent development, I've been trying to do it all in one go as you suggest. However, in order to do it all in one go, you still need to know *what* to replace all the deprecated-and-deleted things with; that's not immediately obvious by just browsing through the arch vector. And it's quite easy to implement some but not all of a set of mutually interacting or interdependent arch methods and not know until you hit some particular runtime combination of circumstances. > 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. I find it hard to believe that's possible for anyone who comes to the code from fresh. You have spent years working with gdb and have the advantage of knowing your way round the code, and what the replacements for each deprecated thing are; anyone else has to do lots of research. If there's going to be a formalization of the deprecation process, my 'feature request' would be that there be one single central place where all deprecated features are listed together with brief pointers to the new functionality that has taken their place. cheers, DaveK -- Can't think of a witty .sigline today....