From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 254EF3858C52 for ; Fri, 3 Feb 2023 15:49:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 254EF3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675439360; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XV2YlOpqfXRS7yLzdkMzE2GEMz0MNz2LW8KZ2ELyLds=; b=WmNnmObqkoNjrL1DYcP32GAnV7S84qkOrwViaOJBLEORY+zSZ5j2Kj3o35Qhcgxop74MRY nx0DrdeRK8FcRd2el9Ma4xkw66Mrq+W9rI5oOFkBy77NGP6P5+iRgsdwsIktzP+XH7GXtt gTEvYX4midn+TxvYI6FrhxVd3Ielw10= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-530-ev3qe8L2OGaPth_atKVw4w-1; Fri, 03 Feb 2023 10:49:12 -0500 X-MC-Unique: ev3qe8L2OGaPth_atKVw4w-1 Received: by mail-qk1-f197.google.com with SMTP id v186-20020a37dcc3000000b0072a264a6208so3539581qki.21 for ; Fri, 03 Feb 2023 07:49:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XV2YlOpqfXRS7yLzdkMzE2GEMz0MNz2LW8KZ2ELyLds=; b=qoE0WGVXCO6G12Kgza6pG7yamcU5VYsB9omVSQy1RkCS2FiHfZseVJUaAWzSlJIvT8 zvn3/+uH7VxLx3AEJKTmgqtKkN4tpibDtUzVfZtPvMNhl4sHSNszUk3BriRlcJqlzeCw PHq7t3Xn1+K3nMgqatZ6c78EnN4mXipN9aN+1ofhO/MzZkcQnawsP2mO4W04QBk3YTTg cFpofMIiCMW7ktLVNsH2B6Ce/HCH1t4fXc9zrrjxO9HBRqNCIQHRV8F0/sif8C225RWv j3vF5jbSKh2i0oJhB8vqqQBLjCBRfm0EEvMNtgE7lYrWOsk1DsaQLsXQwzCIew+cU/DB 0A4Q== X-Gm-Message-State: AO0yUKVyShvjHZ5XoIZc+5Tdk0la0+zRe6m+780BVYUtce/hU+JgJL8z sB1mHHR/P/1pmixNp5JGG2MwSa84UMUQNDcFHTcfG0wPMIvlOdi80An32ktK/4gDvtV3i3XLxW8 TsyETbUvI6GzdfRwZ/bhcg6/dafswajsS1hSbiegF02EyhKH5QWbfB8QnFzIFzCKO3Exman9bEg == X-Received: by 2002:a05:622a:1003:b0:3b6:309e:dfdb with SMTP id d3-20020a05622a100300b003b6309edfdbmr19162506qte.22.1675439351465; Fri, 03 Feb 2023 07:49:11 -0800 (PST) X-Google-Smtp-Source: AK7set9tqA3GT+CahRnjNibPXOTAUWRFYyBS1l07kWZrt/grPnYe3a7xvLGeIS2OKUtQTFi0FL/dow== X-Received: by 2002:a05:622a:1003:b0:3b6:309e:dfdb with SMTP id d3-20020a05622a100300b003b6309edfdbmr19162464qte.22.1675439351064; Fri, 03 Feb 2023 07:49:11 -0800 (PST) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id o28-20020ac8429c000000b003b880ef08acsm1785765qtl.35.2023.02.03.07.49.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Feb 2023 07:49:10 -0800 (PST) From: Andrew Burgess To: Bruno Larsen via Gdb-patches , gdb-patches@sourceware.org Cc: Bruno Larsen Subject: Re: [PATCH 2/2] gdb/testsuite: fix running gdb.linespec/cp-completion-aliases.exp with clang In-Reply-To: <87a61usw1t.fsf@redhat.com> References: <20230117130007.1686917-1-blarsen@redhat.com> <20230117130007.1686917-3-blarsen@redhat.com> <87a61usw1t.fsf@redhat.com> Date: Fri, 03 Feb 2023 15:49:08 +0000 Message-ID: <877cwysqa3.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Andrew Burgess writes: > Bruno Larsen via Gdb-patches writes: > >> Currently, all important tests in gdb.linespec/cp-completion-aliases.exp >> are failing when using clang because the wrong type is being suggested >> for the completion. For example, running with gcc and clang we get the >> following output respectively: >> >> (gdb) break get_value(object_p) <- gcc version >> (gdb) break get_value(object*) <- clang version > > You are correct that what we print for Clang is not wrong. But I don't > think it's as correct as what we print for GCC. The user wrote > object_p, and the DWARF does encode the object_p for both versions. > It's just in the Clang case there's an extra DW_AT_linkage_name which > seems to send GDB off doing the "wrong" thing. > > I wonder how hard it would actually be to "fix" this so that we print > object_p for Clang? I think it would be helpful to really understand at > which point we diverge when comparing Clang and GCC binaries. The diff below fixes this issue for the specific test that you were editing. I've not tested this at all beyond that one test. But I wonder if something like this makes sense? What's happening is that when we read the DWARF we end up calling dwarf2_physname to figure out the name of the symbol. If the DIE has a linkage name then we just demangle that, and use that as the symbol name. But, at least for C++ I don't think that makes sense. We know that the demangled name will have stripped any typedefs. While the computed name will better reflect what's actually written in the code. We already have something similar in place for Rust (commit 906bb4c58faa). Anyway, just and idea... Thanks, Andrew --- diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index ee4e7c1530a..00c46197e3c 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -9133,7 +9133,7 @@ dwarf2_physname (const char *name, struct die_info *die, struct dwarf2_cu *cu) if (!die_needs_namespace (die, cu)) return dwarf2_compute_name (name, die, cu, 1); - if (cu->lang () != language_rust) + if (cu->lang () != language_rust && cu->lang () != language_cplus) mangled = dw2_linkage_name (die, cu); /* DW_AT_linkage_name is missing in some cases - depend on what GDB