From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1151 invoked by alias); 12 Feb 2008 01:08:16 -0000 Received: (qmail 1142 invoked by uid 22791); 12 Feb 2008 01:08:15 -0000 X-Spam-Check-By: sourceware.org Received: from qnxmail.qnx.com (HELO qnxmail.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 12 Feb 2008 01:07:57 +0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.42.96.5]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id TAA22259; Mon, 11 Feb 2008 19:53:19 -0500 Received: from [192.168.20.245] (pptp_vpn-20-245 [192.168.20.245]) by smtp.ott.qnx.com (8.8.8/8.6.12) with ESMTP id UAA10929; Mon, 11 Feb 2008 20:07:55 -0500 Message-ID: <47B0F16B.9090308@qnx.com> Date: Tue, 12 Feb 2008 01:08:00 -0000 From: Aleksandar Ristovski User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sourceware.org Subject: Re: [patch] Do not add partial_symbol again and again to the list References: <47B0AEC7.3070400@qnx.com> <20080211203809.GA29560@caradoc.them.org> <47B0B56F.4010607@qnx.com> <20080211210935.GA31767@caradoc.them.org> <47B0C0F4.4090302@qnx.com> <20080211214750.GA1953@caradoc.them.org> <47B0C7C6.9090605@qnx.com> <20080211223056.GA3833@caradoc.them.org> <47B0CF8A.6080306@qnx.com> <20080211225314.GA5832@caradoc.them.org> In-Reply-To: <20080211225314.GA5832@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2008-02/txt/msg00193.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Feb 11, 2008 at 05:43:22PM -0500, Aleksandar Ristovski wrote: >> If one compilation unit has a list of symbols and they appear more than >> once... do we really need to have all duplicate records in partial symbols >> list? The partial symbol lookup (by symbol name) will find only the first >> one matching and probably cause loading the full symbols at which point >> all works as before. > > Sure. But your patches aren't checking one compilation unit, they're > checking every compilation unit in the objfile at once. That's why > they found duplicates. I don't think any one compilation unit will > have a duplicate. Then I am definitely missing something big. Please correct me where I'm wrong. struct dwarf2_cu has a pointer to struct objfile, which (if I'm not mistaken) get's allocated per compilation unit. Further, struct objfile contains pointer to struct bcache: psymbol_cache which gets initialized in objfile initialization (allocate_objfile function). Therefore, there should be exactly one psymbol_cache per objfile. bcache_data hashes objects in psymbol_cache, that is, it will hash only partial symbols of that particular compilation unit. There are two pointers to struct psymbol_allocation_list, both declared in struct objfile: global_psymbols and static_psymbols. Therefore, there should be exactly one of each per each compilation unit. In dwarf2read.c we determine whether a symbol belongs to the global or static psymbol list and we pass this list along with the objfile pointer to add_psymbol_to_list function. Now we get to the point where I made the change: The first patch I submitted allows for having a psymbol listed in each list, but only once (as opposed to many times before). The second patch I submitted will prevent adding a partial symbol to both lists. What am I missing? > >> Not sure if it is a valid indicator but I didn't have any regressions in >> 'make check'. > > Yeah, I think I could write some testcases that were affected by this, > but I'm not sure. It's tricky because if something else causes the > full symtab to load, the problem won't appear. Yes, that is the tricky part. We want lookup by symbol name to occur in order to test this. Maybe adding a maintenance command that would explicitly lookup a partial symbol by name? > > Maybe there's some way we can avoid needing psymbols for types at all. > But I think we need to have a real design and some documentation for > it instead of just accidentally omitting them. > Not sure how would that work. But I think it would make sense to have only one global_psymbols list.