From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28480 invoked by alias); 13 Nov 2014 16:13:35 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 28408 invoked by uid 89); 13 Nov 2014 16:13:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: usevmg21.ericsson.net Received: from usevmg21.ericsson.net (HELO usevmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 13 Nov 2014 16:13:26 +0000 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 6B.79.25146.47D74645; Thu, 13 Nov 2014 10:44:21 +0100 (CET) Received: from [142.133.110.254] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.96) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 13 Nov 2014 11:13:23 -0500 Message-ID: <5464D8A2.9020004@ericsson.com> Date: Thu, 13 Nov 2014 16:13:00 -0000 From: Simon Marchi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Subject: Re: [PATCH 00/21] struct symtab split part 2 References: In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00271.txt.bz2 On 2014-11-13 07:48 AM, Doug Evans wrote: > Hi. > > This is part 2 of a patch set to split up struct symtab. > Part 1 was here: https://sourceware.org/ml/gdb-patches/2014-11/msg00193.html > > Currently "symtabs" in gdb are stored as a single linked list of > struct symtab that contains both symbol symtabs (the blockvectors) > and file symtabs (the linetables). > > This has led to confusion, bugs, and performance issues. > > This patch is conceptually very simple: split struct symtab into > two pieces: one part containing things common across the entire > compilation unit, and one part containing things specific to each > source file. > > Example. > For the case of a program built out of these files: > > foo.c > foo1.h > foo2.h > bar.c > foo1.h > bar.h > > Today we have a single list of struct symtabs: > > objfile -> foo.c -> foo1.h -> foo2.h -> bar.c -> foo1.h -> bar.h -> NULL > > where "->" means the "next" pointer in struct symtab. > > With this patch, that turns into: > > objfile -> foo.c(cu) -> bar.c(cu) -> NULL > | | > v v > foo.c bar.c > | | > v v > foo1.h foo1.h > | | > v v > foo2.h bar.h > | | > v v > NULL NULL > > where "foo.c(cu)" and "bar.c(cu)" are struct compunit_symtab objects, > and the files foo.c, etc. are struct symtab objects. > > So now, for example, when we want to iterate over all blockvectors > we can now just iterate over the compunit_symtab list. > > Plus a lot of the data that was either unused or replicated for each > symtab in a compilation unit now lives in struct compunit_symtab. > E.g., the objfile pointer, the producer string, etc. > I thought of moving "language" out of struct symtab but there is > logic to try to compute the language based on previously seen files, > and I think that's best left as is for now. > With my standard monster benchmark with -readnow (which I can't actually > do, but based on my calculations), whereas today the list requires > 77MB to store all the struct symtabs, it now only requires 37MB. > A modest space savings given the gigabytes needed for all the debug info, > etc. Still, it's nice. Plus, whereas today we create a copy of dirname > for each source file symtab in a compilation unit, we now only create one > for the compunit. Hi Doug, As someone who never quite understood who the symtab mechanism worked in gdb, I welcome this change very much It makes the data structure a bit more self-descriptive, which in turn helps understanding the algorithms used. That lovely ascii art chart makes things very clear, and I would even suggest including it somewhere in the code (symtab.h I guess). Thanks a lot for your work.