From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79792 invoked by alias); 20 Feb 2020 00:11:11 -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 79783 invoked by uid 89); 20 Feb 2020 00:11:11 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1305 X-HELO: gateway24.websitewelcome.com Received: from gateway24.websitewelcome.com (HELO gateway24.websitewelcome.com) (192.185.51.253) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Feb 2020 00:11:09 +0000 Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway24.websitewelcome.com (Postfix) with ESMTP id 25D7B8CB0 for ; Wed, 19 Feb 2020 18:11:08 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id 4ZQqjEmWFEfyq4ZQqjMVD2; Wed, 19 Feb 2020 18:11:08 -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=3YujbZDR5LYz7jpFS+5QXDfBF+cOBAEyHzTW0Isg5D8=; b=fI8xAbp+HDERt0VC7AQPXWEzGf U5WC6H3MRcXHVn/J0JVcAwPVvXHaFQP/++i6llnDbGWJ2iJKgCK7dyh9Ig31fn1LRUwTKMgK12gFH bznyIFAkvpc7kBVUzvUtEh2VZ; Received: from 75-166-123-50.hlrn.qwest.net ([75.166.123.50]:46732 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j4ZQp-003VKn-UQ; Wed, 19 Feb 2020 17:11:08 -0700 From: Tom Tromey To: Tom Tromey Cc: Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH 01/14] Fix latent bug in dwarf2_find_containing_comp_unit References: <20200215165444.32653-1-tom@tromey.com> <20200215165444.32653-2-tom@tromey.com> <01167589-fae4-39a0-1ebe-0c7d4cbf52b5@simark.ca> <87o8tu3c1g.fsf@tromey.com> Date: Thu, 20 Feb 2020 00:11:00 -0000 In-Reply-To: <87o8tu3c1g.fsf@tromey.com> (Tom Tromey's message of "Wed, 19 Feb 2020 07:08:11 -0700") Message-ID: <87sgj686ec.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/msg00812.txt.bz2 Simon> By refactoring the code a bit, we could maybe factor out the meat Simon> of this function into one that operates on an Simon> std::vector instead of on a Simon> dwarf2_per_objfile. It should then be feasible to create an Simon> std::vector with dwarf2_per_cu_data elements out of thin air to Simon> unit-test the function, including edge cases like this. Here is a new version of this patch. I propose landing it separately, because it is just a straightforward latent bug fix. Simon> Also, do you understand what's the logic with this dwz stuff? Is it that all the CUs Simon> coming from a dwz file are at the end of the list, or something like that? Tom> Yes, exactly. To expand on that, in multi-file mode, dwz may create a combined, shared file of partial symtabs. When reading the DWARF for the main file, gdb may find it needs the dwz file; and in this case the additional CUs are put into the same vector, at the end. It's done this way so that we can easily find the correct CU (since the section offsets between the main and shared dwz file will overlap). It would probably be better to try to share these CUs across objfiles. That may be somewhat involved given the current code, though. Tom