From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31399 invoked by alias); 13 Jun 2003 14:00:58 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31348 invoked from network); 13 Jun 2003 14:00:58 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 13 Jun 2003 14:00:58 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h5DE0vH17698 for ; Fri, 13 Jun 2003 10:00:57 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5DE0vI08740 for ; Fri, 13 Jun 2003 10:00:57 -0400 Received: from localhost.redhat.com (IDENT:x6y6kwS2DUlTQ/pzgmRpu2umMPwIkXqt@tooth.toronto.redhat.com [172.16.14.29]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5DE0te27911; Fri, 13 Jun 2003 10:00:55 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 41DD82C986; Fri, 13 Jun 2003 10:07:24 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16105.55964.91811.625007@localhost.redhat.com> Date: Fri, 13 Jun 2003 14:00:00 -0000 To: Daniel Jacobowitz Cc: David Carlton , Elena Zannoni , gdb , Jim Blandy Subject: Re: DW_AT_specification and partial symtabs In-Reply-To: <20030613133414.GB29641@nevyn.them.org> References: <20030612170545.GA16995@nevyn.them.org> <16104.47067.182016.78574@localhost.redhat.com> <20030613133414.GB29641@nevyn.them.org> X-SW-Source: 2003-06/txt/msg00245.txt.bz2 Daniel Jacobowitz writes: > On Thu, Jun 12, 2003 at 03:16:58PM -0700, David Carlton wrote: > > On Thu, 12 Jun 2003 13:26:51 -0400, Elena Zannoni said: > > > > > I wonder, if we are not reaching the end of the usefulness of the > > > psymtabs. I mean, if we start making the psymtab reader behave like > > > the symtab reader, how much faster is that going to be, how much > > > smaller, etc. > > > > Yeah, I'm starting to wonder that, too. This particular situation is > > enough of an edge case that I'm actually tempted not to fix the > > psymtab reader until I get bug reports from users complaining about > > it, because if I do fix it completely then I'll probably make the > > psymtab reader slow, make it duplicate lots and lots of the > > functionality of the symtab reader, and do it in such a way as to > > cause code duplication that will lead to bugs as the two versions slip > > out of sync. So I'm tempted to let things be for now, and wait until > > .debug_pubtypes comes along to save the day. > > > > I guess another possibility would be to merge the symtab reader and > > psymtab reader, and have there be some variable 'reading_psyms' or > > whatever to control what sort of symbols we're creating, how deeply we > > descend into trees, etc. > > > > It would be interesting to find out the following: > > > > 1) How much is the savings for building a psymtab vs. building a > > symtab? > > > > 2) Where is that savings coming from? > > > > If the savings largely comes from not descending into the bodies of > > functions, then the current structure should go: we should just merge > > the psymtab and symtab readers, but have some flag floating around > > that controls whether or not we descend into bodies of functions. > > 1) is very easy to measure. GDB has a command line option --readnow > which forces symtabs to be read in immediately. I tried my normal > performance testcase: a dummy main() linked to all of mozilla's > component libraries, with full stabs debug info. Note stabs, not > DWARF2, so the timing may vary. Also note that we duplicate psymtab > and symtab creation doing it this way, so it overestimates the cost. > But it should give you an idea. > > Psymbols 5.3: > gdb --batch -x a ./mozilla-libs 17.34s user 1.72s system 78% cpu 24.160 total > > Psymbols and symbols 5.3: > gdb --batch -x a ./mozilla-libs --readnow 41.20s user 4.93s system 83% cpu 55.207 total > > Psymbols CVS: > /opt/src/gdb/x86-as/gdb/gdb --batch -x a ./mozilla-libs 8.79s user 1.01s system 99% cpu 9.850 total > > Psymbols and symbols CVS: > /opt/src/gdb/x86-as/gdb/gdb --batch -x a ./mozilla-libs --readnow 30.45s user 2.70s system 94% cpu 35.131 total > > Note that none of those times is really acceptably fast, IMHO. Probably > they all can be improved. Looking at profiling data I see about three > seconds we can knock off the symbol reader and there are almost > certainly more. But with --readnow we do both psymtabs and symtabs. I wonder, if we didn't do psymtabs at all, the time would improve, one hopes. And the memory footprint would shrink too. > > Andrew's suggested in the past that (rather than all-at-once) we read > symbols lazily; that's essentially like the status quo but without a > separate psymtab table. I don't know how much that saves us. > > Keep in mind that symbols are (at present) rather memory-intensive > compared to psymbols. Also keep in mind that we build more type > information when reading symbols - more time, more memory. > > One quick thing we can do to speed up DWARF2 symbol reading is to > finish converting the rest of GDB to runtime-computed locations; then > we won't have to parse location lists or location expressions at > load time. > yes, that's a clear win. elena > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer