From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5095 invoked by alias); 11 Feb 2008 22:43:44 -0000 Received: (qmail 5083 invoked by uid 22791); 11 Feb 2008 22:43:42 -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; Mon, 11 Feb 2008 22:43:25 +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 RAA21810; Mon, 11 Feb 2008 17:28:48 -0500 Received: from [10.42.100.129] (dhcp-100-129 [10.42.100.129]) by smtp.ott.qnx.com (8.8.8/8.6.12) with ESMTP id RAA14633; Mon, 11 Feb 2008 17:43:23 -0500 Message-ID: <47B0CF8A.6080306@qnx.com> Date: Mon, 11 Feb 2008 22:43: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> In-Reply-To: <20080211223056.GA3833@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/msg00191.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Feb 11, 2008 at 05:10:14PM -0500, Aleksandar Ristovski wrote: >> unsigned int >> _GCC_ATTR_ALIGN_64t >> long long int >> _GCC_ATTR_ALIGN_u64t >> long long unsigned int >> _Int64t > > OK, I remember what's going on now. I think you've missed something > about these lists. > > Suppose we've got two C files combined into one objfile by the linker. > One has "typedef long long _Int64t" and the other has "typedef struct > { int hi, int lo; } _Int64t". GDB records that type as present in > both files. All the partial symbol says is that there's a typedef > named _Int64t; it doesn't say what it's typedef'd to. Because it's > a typedef, the DWARF-2 reader adds it to the list of file-scope > symbols. > > There's a single list of file-scope partial symbols for the whole > objfile, objfile->static_psymbols. Each psymtab has an offset > (statics_offset) saying where in that file-wide list of symbols to > look for static symbols for this particular file. So it's a single > "list", but it contains many individual lists. That's why there's > a bcache; many files may have identical psymbols, but the psymbol > belongs to each individual file. > > Your patch leaves the types out of every file after the first. I > believe it will cause GDB to fail to locate the correct type or > enumerator. Functions will be unaffected, since the psymbol includes > the address, so there won't be duplicates anyway. We don't know > at this stage of processing if the typedef, struct, or enumerator > in the new file has the same value as the one in the previous file; > we don't have values until we read in full symbols. > 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. Not sure if it is a valid indicator but I didn't have any regressions in 'make check'.