From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20721 invoked by alias); 22 Feb 2004 06:01:58 -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 20712 invoked from network); 22 Feb 2004 06:01:58 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 22 Feb 2004 06:01:58 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.30) id 1AumgU-00007R-1X; Sun, 22 Feb 2004 01:01:46 -0500 Date: Sun, 22 Feb 2004 06:01:00 -0000 Message-Id: From: Eli Zaretskii To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com In-reply-to: <20040222010117.GA13487@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 21 Feb 2004 20:01:17 -0500) Subject: Re: [intercu] Handle simple DIEs pre-emptively Reply-to: Eli Zaretskii References: <20040222010117.GA13487@nevyn.them.org> X-SW-Source: 2004-02/txt/msg00595.txt.bz2 > Date: Sat, 21 Feb 2004 20:01:17 -0500 > From: Daniel Jacobowitz > + > + /* This two-pass algorithm for processing partial symbols has a high > + cost in cache pressure. Thus, handle some trivial cases here > + which cover the majority of C partial symbols. DIEs which > + neither have specification tags in them, nor could have specification > + tags elsewhere pointing at them, can simply be processed and > + discarded. > + > + This segment is also optional; scan_partial_symbols and > + add_partial_symbol will handle these DIEs if we simply chain > + them in normally. When compilers which do not emit large > + quantities of duplicate debug information are more common, > + this code can probably be removed. */ More nit-picking: please use TABs and spaces consistently here. "M-x tabify" is your friend.