From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) by sourceware.org (Postfix) with ESMTPS id 103A93858D1E for ; Fri, 29 Apr 2022 17:26:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 103A93858D1E 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-f48.google.com with SMTP id w4so11624832wrg.12 for ; Fri, 29 Apr 2022 10:26: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:from:to:cc:references:in-reply-to :content-transfer-encoding; bh=055j6KYL9dlTzPsEKmzT1xCLuSBeggtdv/GMwP6n7zM=; b=1vxKZcGnMvwyFGQEwRK17NgUtc3OnEtMn2ZgZ4yiOsgc9FpDduuugg4J2o278LNVXY mW7fv5NsHkbjglpa28nG96//CMy0xYq54F7GR0DTBV8AXMxl6k5K62l9Dp255+WAPFdK YTdLxR88xy6Ckh5Nlh+oEAFUrzwnKPRUnKUelDe8NFxc+0n2HouuoHx0cRAtUn8zYx2K xhwxBPKxHvFTpY46QgIJ+UNOzBQD1OzztoxDIWGtvob5mRg8J4A3YeBJVSejt23yXSAH 9ikFCigfMwY+dfLP/b37heENhxzQ2LNZwEaZ6LxdBeecUSabF1UenWHuRpgL83grt04f 0bVA== X-Gm-Message-State: AOAM531F1gpdXfnus5Wl2MOSYFmZS2LtdeuEuY0NYcwhJ1P9q346U3Ur VlgFtfj4TNFamWs18Xy0wF+BU9zkY6tYtw== X-Google-Smtp-Source: ABdhPJz8Jg6ITV24eX3ElJJeUj5RefF8pLz4Gdw9WprnPV8lLrXisPM7OVJzsyXWHDGBnYmFGf6jCw== X-Received: by 2002:a05:6000:1a86:b0:20c:4014:dfe2 with SMTP id f6-20020a0560001a8600b0020c4014dfe2mr111234wry.513.1651253205030; Fri, 29 Apr 2022 10:26:45 -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 m6-20020a1c2606000000b00393fbf75a56sm3050195wmm.29.2022.04.29.10.26.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 10:26:44 -0700 (PDT) Message-ID: <77a0bb58-c434-de4a-1707-f65a7c438a79@palves.net> Date: Fri, 29 Apr 2022 18:26:42 +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 From: Pedro Alves 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> <31261461-8f2a-8919-c882-3601a9adefd9@palves.net> In-Reply-To: <31261461-8f2a-8919-c882-3601a9adefd9@palves.net> 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:26:47 -0000 On 2022-04-29 18:20, Pedro Alves wrote: > 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 Sigh, wrong url, obviously. I meant, this: https://sourceware.org/pipermail/gdb-patches/2011-June/083081.html Pedro Alves > > 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.