From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25395 invoked by alias); 21 Feb 2020 23:36:55 -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 25387 invoked by uid 89); 21 Feb 2020 23:36:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.3 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: gateway30.websitewelcome.com Received: from gateway30.websitewelcome.com (HELO gateway30.websitewelcome.com) (50.116.127.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 21 Feb 2020 23:36:53 +0000 Received: from cm17.websitewelcome.com (cm17.websitewelcome.com [100.42.49.20]) by gateway30.websitewelcome.com (Postfix) with ESMTP id 1944B5635 for ; Fri, 21 Feb 2020 17:36:51 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id 5HqljgJHvAGTX5HqljqdFr; Fri, 21 Feb 2020 17:36:51 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=NSoLqqK2SkrXQLZZZ5gst5+BuLUKZi7loYJyn8kUTjI=; b=oV+3SFXhBdatf/HlrVLpctdGkg 1eTh34/drbZDdBJhagifBJXboydkU3Mg1eR5fQ2ra59H67NNjg8lOCXW6GPdCWA6jkwcqg6i3a0rk 1at41dASVfpOxTw1hofpKkPWv; Received: from 75-166-123-50.hlrn.qwest.net ([75.166.123.50]:53580 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j5Hqk-001amg-SH; Fri, 21 Feb 2020 16:36:50 -0700 From: Tom Tromey To: Luis Machado Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH 07/14] Add dwarf2_per_cu_data::index References: <20200215165444.32653-1-tom@tromey.com> <20200215165444.32653-8-tom@tromey.com> <467b34b2-5fea-95a0-6557-b08e64338bd0@linaro.org> Date: Fri, 21 Feb 2020 23:36:00 -0000 In-Reply-To: <467b34b2-5fea-95a0-6557-b08e64338bd0@linaro.org> (Luis Machado's message of "Tue, 18 Feb 2020 08:38:57 -0300") Message-ID: <877e0f8qct.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2020-02/txt/msg00869.txt.bz2 >>>>> "Luis" == Luis Machado writes: >> static dwarf2_per_cu_data * >> create_cu_from_index_list (struct dwarf2_per_objfile *dwarf2_per_objfile, >> - struct dwarf2_section_info *section, >> - int is_dwz, >> - sect_offset sect_off, ULONGEST length) >> + struct dwarf2_section_info *section, >> + int is_dwz, >> + sect_offset sect_off, ULONGEST length) Luis> Did only formatting change above? Yeah. I backed this bit out. >> + /* A convenience function to allocate a dwarf2_per_cu_data (or >> + object holding one, using C-style derivation). The returned >> + object has its "index" field set properly. The object is >> + allocated on the dwarf2_per_objfile obstack. FIXME the index >> + here is weird since it may not (!?!?) be the same as the other >> + index */ Luis> I'm a bit lost on the above comment. Instead of having a FIXME here, Luis> is there something we can do better at this point? Or maybe it will be Luis> addressed later in the series? Luis> I couldn't quite understand the problems with the indexes, but you're Luis> more familiar with the DWARF reading code than i am. I updated the comment, and added a comment by allocate_signatured_type. Part of that comment referred to some earlier code that also tried to unify signatured_type and type_unit_group into this allocation function. The FIXME was more of a note to myself about whether this index could somehow be reused, because the reader sometimes uses an index to look in all_comp_units and all_type_units. I think it turns out they are equivalent, but it seems like it doesn't matter, because there's no need to use this value to index into the all_type_units / all_comp_units vectors. >> + /* Our index in the unshared "all_cutus" vector. */ >> + unsigned index; Luis> What is the all_cutus vector? I don't see it being added later in the Luis> series. Should we make it more clear? Maybe you meant "all CU's/TU's"? I changed it to "symtabs" as Simon pointed out down-thread. Tom