From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19136 invoked by alias); 19 Sep 2002 02:25: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 19125 invoked from network); 19 Sep 2002 02:25:09 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 19 Sep 2002 02:25: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 17rrwC-0006iE-00 for ; Wed, 18 Sep 2002 22:25:08 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17rr0D-0008FV-00 for ; Wed, 18 Sep 2002 22:25:13 -0400 Date: Wed, 18 Sep 2002 19:25:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFA] delete BLOCK_SHOULD_SORT Message-ID: <20020919022513.GA31571@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00449.txt.bz2 On Wed, Sep 18, 2002 at 03:15:40PM -0700, David Carlton wrote: > I'd like to delete all occurences of BLOCK_SHOULD_SORT from GDB; it's > really no longer necessary, and will get in the way of my dictionary > work. > > The history, as I understand it, is that formerly symbols in blocks > were always stored linearly; but, for blocks where the order didn't > matter, the symbols were sorted to improve search time. Then blocks > using hashtables were introduced; these are now used almost everywhere > that sorted linear blocks had been previously used. In particular, > blocks produced by buildsym.c, which is the vast majority of blocks, > will never satisfy BLOCK_SHOULD_SORT. ... > So, basically, making this change will get rid of some cruft, make an > unnoticeable speed improvement to symbol manipulation stuff for normal > usage, and when debugging ECOFF files, symbol table lookup will be a > bit slower. (But it will still be correct: this is removing an > optimization, but the unoptimized behavior will still work.) If > anybody out there actually uses ECOFF and is bothered by this, clearly > the best thing would be for that person to convert mdebugread.c to use > the mechanisms in buildsym.c just like every other debugging format > reader. > > I think the changes are pretty straightforward, though I'd appreciate > it if somebody more conversant with ada-lang.c than I am could make > sure I'm not missing anything with my change there. For what it's worth, it all looks good (and worth doing!) to me. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer