From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14239 invoked by alias); 17 Sep 2002 19:59:10 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14230 invoked from network); 17 Sep 2002 19:59:10 -0000 Received: from unknown (HELO mail.cdt.org) (206.112.85.61) by sources.redhat.com with SMTP; 17 Sep 2002 19:59:10 -0000 Received: from www.dberlin.org (pool-138-88-97-198.res.east.verizon.net [138.88.97.198]) by mail.cdt.org (Postfix) with ESMTP id 66E99490063; Tue, 17 Sep 2002 15:36:40 -0400 (EDT) Received: from dberlin.org (unknown [192.168.0.252]) by www.dberlin.org (Postfix) with ESMTP id C911B1805C4C; Tue, 17 Sep 2002 15:59:08 -0400 (EDT) Date: Tue, 17 Sep 2002 12:59:00 -0000 Subject: Re: [RFA] convert blocks to dictionaries, phase 1, main part Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Daniel Jacobowitz , David Carlton , gdb-patches@sources.redhat.com To: Andrew Cagney From: Daniel Berlin In-Reply-To: <3D877828.2050607@ges.redhat.com> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00359.txt.bz2 On Tuesday, September 17, 2002, at 02:44 PM, Andrew Cagney wrote: > >> Basically, at any point when you don't have a lot of temporary gunk. >> I >> confess, I'm of two minds about working on a branch for this sort of >> thing: >> I consider it very impractical for things which don't break up into >> pieces easily afterwards. GCC has been using an interesting approach, >> which I think we could adapt and extend here. > > GCC's approach relies on GCC's development cycle: break, fix, release. > You can only pull stuff in from those branches during the ``break'' > phase. And during that phase, things, from what I've seen, really are > broken (I got stuck trying to commit a patch because I couldn't > build/test GCC for several weeks). > > I also, to be honest, think that GCC has bigger problems than GDB. > With GDB, the basic architecture is fine (if you look at the > relationships and ignore all the globals and messed up interfaces :-). > GCC, on the other hand, needs some of its fundamental data structures > and algorithms completly replaced. This is mistaken. Not that GCC doesn't need things completely replaced, but that GDB is fine. It's symbol table, debug info reader, location evaluation, etc, needs some of its fundamental data structures and algorithms completely replaced. I'd agree that the non-debug info related architecture is fine (IE multiarch and whatnot), excluding the way threads are handled. But both GCC and GDB have these problems for the same reasons: They were not designed to handle the complexities that they are now required to handle. The scale up in terms of project size has been absurd in the past few years. GCC has resigned itself to deal with these cases. GDB has ignored them for the past few years, because nobody has had the time to do the replacements of algorithms and data structures, to handle things like namespaces, etc. This doesn't, however, mean it doesn't need to be done. --Dan