From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83401 invoked by alias); 21 Oct 2019 20:05:43 -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 83393 invoked by uid 89); 21 Oct 2019 20:05:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=inherited, recall, dictionary, spent X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 21 Oct 2019 20:05:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571688340; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YVBPOMJRheAcHlGM15+acu8HVY7bQ6S+Dvzq93Paeio=; b=hA32JHs5p8H+hVagrUquG8i2N8u1KIgxtdvqdteSHKcjpZpKvWzgPR2fWhwoyD+R1DjrCc Orz6+Uw2yccupb2qM1HOVHFXrqJIMR7zQi89A2VJ9JyRvcS0CKEB3AoYcSf0glCk8jmchN Uv7l7ZZusNZmu8H4wNB41lYhYEcabII= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-250-cYjDyaMjPIi0wQLu2SUo7Q-1; Mon, 21 Oct 2019 16:05:38 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 90EF4800D41; Mon, 21 Oct 2019 20:05:37 +0000 (UTC) Received: from theo.uglyboxes.com (ovpn-116-179.phx2.redhat.com [10.3.116.179]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4D70D5D6A5; Mon, 21 Oct 2019 20:05:37 +0000 (UTC) Subject: Re: [PATCH 1/2] Fix BZ 25065 - Ensure that physnames are computed for inherited DIEs To: Simon Marchi , 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> <20191017180851.7db69958@f29-4.lan> <8b301205-e8f6-ead5-0484-eacfb82e5b7a@polymtl.ca> From: Keith Seitz Message-ID: <9d4006e3-8155-ad45-c7d4-ff83c9e741da@redhat.com> Date: Mon, 21 Oct 2019 20:05: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: <8b301205-e8f6-ead5-0484-eacfb82e5b7a@polymtl.ca> X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00747.txt.bz2 On 10/18/19 8:07 AM, Simon Marchi wrote: >> I spent a little time trying to figure out what CU is used for in >> dwarf2_physname() and its callees. What I noticed most is that >> cu->language is used to figure out some appropriate thing to do. >> I seem to remember Keith running into problems with mismatched >> languages in different CUs. So there might be problems if the >> languages associated with the CUs are different. >=20 > Yeah, I remember this saga, but I did not really follow it. Keith, would > you have an idea of what would be the right CU to pass here? The language mismatch that Kevin refers to was a problem that appeared with LTO. The primary DIE would be marked artificial and having language C9= 9. That DIE would then import other DIEs of different languages (mostly C++), and that would cause problems because all these symbols are supposed to live in the same dictionary. That was resolved by moving to multidictionary a while back. [Reminder, a symbol's language is used for searching. Differe= nt languages now have different searching algorithms. This was introduced to help with Pedro's multi-breakpoint/linespec work to deal with namespaces, ABI tags, etc.] As far as the correct DIEs to use when passing to dwarf2_physname, I don't think/remember it being anything particularly unexpected. If the physname for a DIE is computed, the DIE/CU passed must be able to give us this information. Since dwarf2_physname largely uses linkage names nowadays (there was only one or two instances where we actually needed to compute the physname), the correct CU/DIE would be the pair containing DW_AT_linkage_name for the symbol. It is debatable whether we even still need delayed physnames. I don't think we actually need to compute physnames much anymore. [As I recall, one place we've had to do this with was dtors. GCC did not emit linkage names for them.] Keith