From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) by sourceware.org (Postfix) with ESMTPS id 12F683858D1E for ; Fri, 29 Apr 2022 17:20:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 12F683858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f51.google.com with SMTP id i5so11611519wrc.13 for ; Fri, 29 Apr 2022 10:20:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=C6TUJrbg1YkdpL2Bz9AOl5zDRIXbpggPJNekIpnbtlw=; b=XZf77CPMrde2HRjGKJ/LhhSWLERvqIitFMITdEd4SGcVJoI+rk0R4FEpfSB0jyuVNe C5rQ2R/F1IVKENq45LTXLhO1FnJ0L1QIBk/2Rh5aK9a4TT0hIYB3uBnRpLz9q+3euIBQ 93ph2f7HBpsBsrUkZjyajjsWJflxt26s3Gu6F9ZFaqGn2XWKJ7DGx8IBEYJmJezydPCu 4QudnAcNUDZekSod4qcgPaM/mxvh1X/cL4Dg36dRbpGMfjW7lWJdEsfwKIHM1E6mDPgV 4nG24l/Pz7ldAVaEndi/3tzPLr+c0Bz0bM86FoYeFvOhF3RyLmKW1oMRVO+bNcNtua9x bGPA== X-Gm-Message-State: AOAM530L998Ia+X7Itb4tcaT1cSGmWss3SDyukX3822VcbNq1iFAzXwZ n1jdFvl8PPod/K0+sJvc508= X-Google-Smtp-Source: ABdhPJyu6k5T3c72QaMLV8+9gymeeHENQd8IXITcHsXHb/DH4OvSZIUYfdNejgeNzT37C/rWIJ1n6A== X-Received: by 2002:a5d:6d05:0:b0:20a:91e4:4b7f with SMTP id e5-20020a5d6d05000000b0020a91e44b7fmr153024wrq.190.1651252844045; Fri, 29 Apr 2022 10:20:44 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id l5-20020adfa385000000b0020adb3ae75dsm2967022wrb.3.2022.04.29.10.20.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 10:20:43 -0700 (PDT) Message-ID: <31261461-8f2a-8919-c882-3601a9adefd9@palves.net> Date: Fri, 29 Apr 2022 18:20:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH] Fix gdb.cp/no-dmgl-verbose.exp test Content-Language: en-US To: Keith Seitz , Carl Love , Lancelot SIX Cc: Ulrich Weigand , gdb-patches@sourceware.org, Rogerio Alves References: <5ee342cd5f5272da9970da8a077c2c5209b85d6c.camel@us.ibm.com> <20220429091234.62xhprge74gfpgks@ubuntu.lan> <4610920e52ea1bbeb5181c970887eb7cfe344f1a.camel@us.ibm.com> <032437ea-2ef4-90f5-7b96-8a729bae2252@redhat.com> From: Pedro Alves In-Reply-To: <032437ea-2ef4-90f5-7b96-8a729bae2252@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 29 Apr 2022 17:20:47 -0000 On 2022-04-29 18:09, Keith Seitz wrote: > 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.] Thanks Keith! That leads to this: https://sourceware.org/pipermail/gdb-patches/2011-July/thread.html The "Test loading symbols from unrelocated C++ object files." intro is found in gdb.cp/cp-relocate.exp:# Test loading symbols from unrelocated C++ object files. so I guess that Jan copied that testcase, and didn't update the intro. The "unrelocated" aspect seems like not important for the test. Note how Jan says: "After Keith's fix of GDB PR 12266 GDB should resolve mostly any form (typedefed/untypedefed etc.) of the user entered function parameters." I believe that should be true today, and GDB should be able to set a breakpoint on the typedef'ed f(std::string), no? I find it very hard to believe that Jan didn't notice that the gdb_breakpoint {'f(std::string)'} call was failing back then. From the message, it very much seems like it was passing back then. And then, the other test: gdb_test {break 'f(std::basic_string, std::allocator >)'} \ {Function ".*" not defined\.} \ "DMGL_VERBOSE-demangled f(std::string) is not defined" means that "std::basic_string, std::allocator >" is what you get when you demangle the function's linkage name with DMGL_VERBOSE, which is different from what you get if you demangle without DMGL_VERBOSE, and this test is thus making sure that such a demangled name is not defined. The proposed change completely turns the testcase on its head.