From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27279 invoked by alias); 17 Sep 2002 20:32: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 27272 invoked from network); 17 Sep 2002 20:32:09 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 17 Sep 2002 20:32:09 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17rPwL-0004Rf-00; Tue, 17 Sep 2002 16:31:26 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17rP0G-0007w8-00; Tue, 17 Sep 2002 16:31:24 -0400 Date: Tue, 17 Sep 2002 13:32:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: David Carlton , gdb-patches@sources.redhat.com Subject: Re: [RFA] convert blocks to dictionaries, phase 1, main part Message-ID: <20020917203124.GA30125@nevyn.them.org> Mail-Followup-To: Andrew Cagney , David Carlton , gdb-patches@sources.redhat.com References: <20020917143553.GA28408@nevyn.them.org> <20020917174928.GA23058@nevyn.them.org> <3D877828.2050607@ges.redhat.com> <20020917193007.GA27789@nevyn.them.org> <3D87874F.8010603@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D87874F.8010603@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00367.txt.bz2 On Tue, Sep 17, 2002 at 03:49:35PM -0400, Andrew Cagney wrote: > >On Tue, Sep 17, 2002 at 02:44:56PM -0400, 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. > > > > > >I think this is just as true of GDB. > > Can you expand. GCC is getting an entirely new tree representation. I > don't see GDB getting anything that fundamental. Symbol reading could use an overhaul - as Daniel likes to point out, there's no reason to be carrying psymtabs around for DWARF-2. Threads support is a little pulled-together under the hood - see w_f_i and tell me it doesn't need to be redone. A lot more of GDB's data structures for state should be per-thread. GDB should be properly asynchronized so that code can run with one thread stopped without having to force-stop all other threads; that's a horribly intrusive wart. I have several times mentioned my intent to overhaul the parsing of CLI commands before the next release, if I can find a moment. I'm doing equally violent things to C++ although a lot of them need to wait on improvements in symbol lookup and eventually in the DWARF-2 reader. We can't debug inline functions much to speak of and we could; this requires serious infrastructure changes and serious interface changes that no one's had a chance to work on. In even more areas, GDB is desperately need of the rewrite that parts of GCC are getting. We just don't have anyone willing to do them! > >>>How about a branch which require approval just like the mainline for > >>>large patches, although giving David a little more freedom to play > >>>around. Then, we'd allow large merges from the branch back to the > >>>trunk when they were ready and tested - larger patches than we'd > >>>normally accept all at once, because they'd already been approved. > >>> > >>>Andrew - thoughts? Does it have any interesting possibilities? > > > >> > >>Let me put it this way, I'm scared shitless of another HP jumbo patch. > > > > > >That's not the point. That's why I suggested a branch which does > >require approval, precisely so that we wouldn't get into that problem. > >But you don't seem to like that idea, so it's dead. > > Me not liking an idea doesn't kill it. It is the symtab maintainers, > and not me that would do the review and hence, they and not me would > need to be ok with it. I was trying to suggest it as a general development practice for GDB, but that is obviously not going to fly. We'll have to wait for Jim or Elena to see how it'll fly in this case. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer