From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75551 invoked by alias); 17 Oct 2019 05:30:36 -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 75445 invoked by uid 89); 17 Oct 2019 05:30:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=heavy X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 Oct 2019 05:30:26 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id x9H5UD7T024181 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Oct 2019 01:30:17 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca x9H5UD7T024181 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1571290218; bh=1FT5XPZpcejg7bNTKlxXjyz6EGLgC3hWapxbkPRnFKc=; h=Subject:From:To:References:Date:In-Reply-To:From; b=l2zJuiDonW8zLaC65VArv2ahKAtTWgmOlEWhtYzLRD3rSTknox1MPF8LMwXdC7zNK QXukA4yZ9VLpDRTaEz2ttaFN8EbANed+pCbW+AQgBX7aCUmaTOUQ7pmKwjyLOTCyFq pV/RQdNvGrPuSwIk50IFMIWezVnZgGEaXL66S0cI= 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 CB3521E50B; Thu, 17 Oct 2019 01:30:12 -0400 (EDT) Subject: Re: [PATCH 1/2] Fix BZ 25065 - Ensure that physnames are computed for inherited DIEs From: Simon Marchi To: Kevin Buettner , gdb-patches@sourceware.org References: <20191014001842.27413-1-kevinb@redhat.com> <20191014001842.27413-2-kevinb@redhat.com> <8c073683bc0b0a8e7918fdfb346cbb03@polymtl.ca> <20191015092743.7037f47c@f29-4.lan> Message-ID: Date: Thu, 17 Oct 2019 05:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00549.txt.bz2 On 2019-10-16 11:54 p.m., Simon Marchi wrote: > I think that what's confusing in all this is the fact that the method_info list is > currently attached to a particular CU. Instead, I think it should be attached to the > operation of processing of a CU, and used to collect all delayed method infos while > processing that CU, even if some of these infos come from inherited DIEs from another > CU. Concretely, it would mean to have a local instance of > std::vector in process_full_comp_unit/process_full_type_unit and to > pass it by pointer/reference through the call stack to any code who might want to append > to it. We wouldn't have to do anything special in inherit_abstract_dies, just pass this > reference to the list down the stack. I don't know how feasible it would be in practice > to do that change, maybe it's too much work or would end up ugly. I'll give it a try. > But your patch gives essentially the same result, and works with what we have today. A little follow up to the above. I prototyped that change here in a WIP patch (so, not intended to be reviewed): https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/128 I got no regression in gdb.dwarf2. However, it's a bit invasive. If we want to pass other objects in the same fashion, it will quickly become very heavy. What we could do though, is to introduce a new type (e.g. struct dwarf2_cu_processing_context) and pass that around instead. Its lifetime would be the duration of process_full_comp_unit / process_full_type_unit, just like std::vector in the patch above, but could contain many fields. I found something potentially problematic though (applies to both your and my patch). When we process the delayed_method_info objects in compute_delayed_physnames, we call: dwarf2_physname (mi.name, mi.die, cu); mi.die could be a die coming from X's CU (to keep the example from my previous message), but the cu in the call above is A's CU (the CU we are processing). I am pretty sure that this function (and what it calls) expect the passed DIE to come from the passed CU. If they don't match, I guess we could have some bad surprises. Simon