From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88518 invoked by alias); 19 Feb 2020 05:31:27 -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 88435 invoked by uid 89); 19 Feb 2020 05:31:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Feb 2020 05:31:13 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id B6F871E5F7; Wed, 19 Feb 2020 00:31:02 -0500 (EST) Subject: Re: [PATCH 07/14] Add dwarf2_per_cu_data::index From: Simon Marchi To: Tom Tromey , gdb-patches@sourceware.org References: <20200215165444.32653-1-tom@tromey.com> <20200215165444.32653-8-tom@tromey.com> <539dc8dc-b35e-690c-ab51-134fc05516a4@simark.ca> Message-ID: <234b15dc-4f9e-ed9d-2493-a4a9916efbd6@simark.ca> Date: Wed, 19 Feb 2020 05:31:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <539dc8dc-b35e-690c-ab51-134fc05516a4@simark.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-02/txt/msg00764.txt.bz2 On 2020-02-18 11:36 p.m., Simon Marchi wrote: > The "all_cutus" vector does not exist (at least at the moment, maybe it's added later > in the series?). I presume you are talking about the logical/combined vector made of > all_comp_units and all_type_units, accessible using dwarf2_per_objfile::get_cutu? > > This logical/combined vector has all the comp units first, then the type units. Using > the new interface allocate_per_cu/allocate_signatured_type, the indices are handed out > in any order. I don't know if it's actually possible to have it in this order, but let's > say we read: > > - a CU > - a TU > - a CU > > The CUs will have been handed out indices 0 and 2, and the TU will have been handed out > index 1. But in reality, when accessing them using get_cutu, the two CUs will be at 0 and > 1, while the TU will be at 2. Again, not sure if it matters, but I thought I would point > it out. > > Or maybe this is what you meant by "the index here is weird since it may not (!?!?) be the > same as the other index", this is not the same index? I guess I'll read the rest of the > series and find out. > > Simon Ok, after reading the next patch I saw that this is indeed referring to an index into another vector. So I suppose it's just that the "all_cutus" reference is stale, it should say "symtabs"?