From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4OZPNv0bbGK/VgMAWB0awg (envelope-from ) for ; Fri, 29 Apr 2022 13:10:21 -0400 Received: by simark.ca (Postfix, from userid 112) id D2E2D1E058; Fri, 29 Apr 2022 13:10:21 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=cqunpODz; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 2B1FE1E00D for ; Fri, 29 Apr 2022 13:10:21 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A68E43858D1E for ; Fri, 29 Apr 2022 17:10:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A68E43858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1651252220; bh=Ybnmw5VCMCtrGgbopElUoiVl+gidb3V9T8cxr+kdFLE=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=cqunpODzpUJOcTi1j25Bt9VdIjj/D3CCQ4Op7B+MkQic8B/wY+kyolTt3WpaW61dc 7T9AnPaqAsbIs3nMaOL3Z3ABe2nzDm4jenWVLYFwguvDJQ+l+X98z7iGdoUj/vavv4 t1DZxbWjByVF6L0rEY2sxNUvaVWe3AGPsmoArklc= 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 1B9033858D1E for ; Fri, 29 Apr 2022 17:10:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1B9033858D1E Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-332-oaUkCrsBOe267vOYQnqVoA-1; Fri, 29 Apr 2022 13:09:53 -0400 X-MC-Unique: oaUkCrsBOe267vOYQnqVoA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0D528381A82B; Fri, 29 Apr 2022 17:09:53 +0000 (UTC) Received: from [10.2.17.203] (unknown [10.2.17.203]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5F80FC15D40; Fri, 29 Apr 2022 17:09:51 +0000 (UTC) Message-ID: <032437ea-2ef4-90f5-7b96-8a729bae2252@redhat.com> Date: Fri, 29 Apr 2022 10:09:49 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH] Fix gdb.cp/no-dmgl-verbose.exp test To: Pedro Alves , Carl Love , Lancelot SIX References: <5ee342cd5f5272da9970da8a077c2c5209b85d6c.camel@us.ibm.com> <20220429091234.62xhprge74gfpgks@ubuntu.lan> <4610920e52ea1bbeb5181c970887eb7cfe344f1a.camel@us.ibm.com> In-Reply-To: X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Keith Seitz via Gdb-patches Reply-To: Keith Seitz Cc: Ulrich Weigand , gdb-patches@sourceware.org, Rogerio Alves Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 4/29/22 09:57, Pedro Alves wrote: > On 2022-04-29 16:48, Carl Love via Gdb-patches wrote: >> On Fri, 2022-04-29 at 09:14 +0000, Lancelot SIX wrote: > > So the file is called gdb.cp/no-dmgl-verbose.exp. "no-dmgl" most certainly means "no demangle". > > How is that related to "no demangle verbose" ? A mystery. I believe I remember some history of this... When I did the physname work years ago, a maintainer objected that the recorded physname for a function which takes a std::string was "reduced" to "std::string" instead of recording (and thus subsequently printing) "std::string" like other tools do. [He speciifcally mentioned "nm".] The "no-dmgl-verbose" refers to the demangler option, DMGL_VERBOSE, which I originally used when computing physnames. I believe this test's intention was to make sure that DMGL_VERBOSE didn't creep back into the code. [Background: At the time, the compiler did not output sufficient debuginfo for a bunch of symbols, such as ctors. Thus the physname computation was a way to "fill-in" this missing/necessary information.] There's a number of other workarounds for this "std::string" vs "std::string" (and others) in cp-support.c. See "ignore_typedefs". [Pardon if my explanation is imprecise. This was a looong time ago.] Keith