From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20332 invoked by alias); 19 Feb 2020 14:08:17 -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 20317 invoked by uid 89); 19 Feb 2020 14:08:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.5 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: gateway33.websitewelcome.com Received: from gateway33.websitewelcome.com (HELO gateway33.websitewelcome.com) (192.185.145.221) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Feb 2020 14:08:14 +0000 Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway33.websitewelcome.com (Postfix) with ESMTP id ABC7E6C7C1 for ; Wed, 19 Feb 2020 08:08:12 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id 4Q1Mj28NwEfyq4Q1Mj9xsu; Wed, 19 Feb 2020 08:08:12 -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=+Hx1BGgAwbz9DulVd4pHsSFiJnJcncJJmkgLw43Qt7w=; b=Cetd5Gg+9YGh4N4eCUT/zG+A4n bU+sfidMTX2nngpUtr0LT7jHgKvzD4EYeVj2yDafftdh7lYtgKhVAn6/yYgl5uNRovSpBsj7g1R2c T6p3hk3d69boECnOvEPuu1cKy; Received: from 75-166-123-50.hlrn.qwest.net ([75.166.123.50]:49754 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j4Q1M-003uI9-D1; Wed, 19 Feb 2020 07:08:12 -0700 From: Tom Tromey To: Simon Marchi Cc: Tom Tromey , 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> Date: Wed, 19 Feb 2020 14:08:00 -0000 In-Reply-To: <01167589-fae4-39a0-1ebe-0c7d4cbf52b5@simark.ca> (Simon Marchi's message of "Tue, 18 Feb 2020 22:42:23 -0500") Message-ID: <87o8tu3c1g.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/msg00774.txt.bz2 >>>>> "Simon" == Simon Marchi writes: Simon> I'm going to ask if you thought about a way to test this. I Simon> don't think writing a typical test case for this is feasible. Yeah. And like I said, I don't remember how I encountered this. Maybe only with some other dubious patch in place. Simon> By refactoring the code a bit, we could maybe factor out the Simon> meat of this function into one that operates on an std::vector instead Simon> of on a dwarf2_per_objfile. It should then be feasible to create an std::vector with Simon> dwarf2_per_cu_data elements out of thin air to unit-test the function, including edge Simon> cases like this. Another idea that occurred to me is that we could just use std::binary_search here. Then instead of implementing a binary search, we'd only need to implement a comparison function -- which seems simpler. Anyway I will try to write a unit test, that's a good idea. 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? Yes, exactly. Maybe this can be cleaned up a bit after this series, since now we have the index directly in the dwarf2_per_cu_data. I am not sure offhand. Tom