From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19580 invoked by alias); 17 Sep 2002 20:13:09 -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 19573 invoked from network); 17 Sep 2002 20:13:08 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 17 Sep 2002 20:13:08 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4D7203DAA; Tue, 17 Sep 2002 16:13:08 -0400 (EDT) Message-ID: <3D878CD4.70803@ges.redhat.com> Date: Tue, 17 Sep 2002 13:13:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Berlin Cc: Daniel Jacobowitz , David Carlton , gdb-patches@sources.redhat.com Subject: Re: [RFA] convert blocks to dictionaries, phase 1, main part References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00363.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. I think of that as evolution, not a revolution. Different view point I guess. Core GDB still views the symbol table the same way, still uses the same basic mechanisms and the same queries (struct symbol, struct block), the back-end just works faster cleaner, better. enjoy, Andrew > 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.