From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-15181-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 22343 invoked by alias); 18 Aug 2003 00:40:35 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 22334 invoked from network); 18 Aug 2003 00:40:27 -0000
Received: from unknown (HELO sj-core-4.cisco.com) (171.68.223.138)
  by sources.redhat.com with SMTP; 18 Aug 2003 00:40:27 -0000
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7I0dXpp009062;
	Sun, 17 Aug 2003 17:39:33 -0700 (PDT)
Received: from asmundaknt3 (dhcp-171-69-59-95.cisco.com [171.69.59.95])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AHE47771;
	Sun, 17 Aug 2003 17:39:32 -0700 (PDT)
Message-ID: <025c01c36521$30e2ec50$5f3b45ab@amer.cisco.com>
From: "Alexander Smundak" <asmundak@cisco.com>
To: "Andrew Cagney" <ac131313@redhat.com>, "Cynbe ru Taren" <cynbe@muq.org>
Cc: <gdb@sources.redhat.com>
References: <200307150234.h6F2YsNW028337@tully.CS.Berkeley.EDU> <87d6f63jes.fsf@muq.org> <3F3E43A5.1000906@redhat.com>
Subject: Re: parallelized 'ld'?
Date: Mon, 18 Aug 2003 00:40:00 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-SW-Source: 2003-08/txt/msg00180.txt.bz2

> [switching mailing lists from binutils@ to gdb@]
>
> > * "gdb used to take inordinate amount of time to load on our platform.
The
> >    fix  was trivial, which likely means that few people ever use GDB on
> >    such large executables."
>
> I believe one identified problem is how the symbol table uses hash
> tables.  The symbol tables are being given a careful upgrade.  Was this
> what you noticed?
No, it is handling BINCL records in STABS. I have replaced the linear search
in dbxread.c, function find_corresponding_bincl_psymtab() with hash table,
and this shaved 3 minutes off the GDB initialization time in our case
(on 333MHz Sparc Ultra).
Please note that our compiler is gcc 2.95, and that this is for STABS
debugging
format. I can send the diffs to the interested parties; they are for 5.0
GDB, though.

Alexander Smundak