From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id XTpiHiwxbGLpWAMAWB0awg (envelope-from ) for ; Fri, 29 Apr 2022 14:40:44 -0400 Received: by simark.ca (Postfix, from userid 112) id 71DBD1E058; Fri, 29 Apr 2022 14:40:44 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,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 5D5971E00E for ; Fri, 29 Apr 2022 14:40:43 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AE8CD3857C4A for ; Fri, 29 Apr 2022 18:40:42 +0000 (GMT) Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by sourceware.org (Postfix) with ESMTPS id 88F0D3858D28 for ; Fri, 29 Apr 2022 18:40:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 88F0D3858D28 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-f52.google.com with SMTP id e24so11855218wrc.9 for ; Fri, 29 Apr 2022 11:40:30 -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=LZOaICWFVS3leugmbJo63V5KvjOm7okrBTrbSPkSIbI=; b=BuRj3IBOQEkSPm1bznuiICh/JhSriDEad6beqNHeQoXVUNO6ih/BrpnQ8eC+3bJ4xa WaiSkALuvSrZXIUtHRru2sREQ8Cxo1vrZpLUXQpWF5OvOVATVj6w5Kpmu7a591N2CTdV CHQaYSCP1KX88BK0FdY16ozhMKVVfT4ArVqlXe1FMmA4hpuLWmKupxDC7nIrslNS7wdZ ckwhX2Pqg3t7y+ekI/zbOaCDxtwvLOK/s5ZRXPCHOK2PE05qpb2pSAZUqVZrxozzOKK2 OHtlppvwmyIuEv7L1ekTRj592sjvdUR9SwXuVIBs7/YOfIt1i4g7dnqlE+rw/oUIQb75 1o5g== X-Gm-Message-State: AOAM530i8J0Cl1kz4Wjt1+M4rUW+w/Gj5X0qA4d9JGSQFop9o1onGafF lskP/tPyvh3c5AHTu719udw= X-Google-Smtp-Source: ABdhPJyAB5sG/pZ14VzuRkdggHHNSAUNqaIEeA5YFQMFWv0+0APRNQCcqSm40kgkByY3eOZG0WBgIg== X-Received: by 2002:adf:9dcc:0:b0:20a:ed44:fd48 with SMTP id q12-20020adf9dcc000000b0020aed44fd48mr375782wre.120.1651257629332; Fri, 29 Apr 2022 11:40:29 -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 q14-20020a1cf30e000000b0038986a18ec8sm3302045wmq.46.2022.04.29.11.40.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 11:40:28 -0700 (PDT) Message-ID: Date: Fri, 29 Apr 2022 19:40:27 +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 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-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: , Cc: Ulrich Weigand , gdb-patches@sourceware.org, Rogerio Alves Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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 > > 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. Thanks for pointing at "ignore_typedefs" in cp-support.c, Keith. So if I hack out that special casing for std::string, like in the patch below, then GDB replaces the typedef, and setting the breakpoint works. However, that only works if we debug a fully linked binary for some reason... If we debug just the .o file, then the symbol still isn't found... That seems yet another bug somewhere. To be clear, with this hack patch below, the testcase passes for me. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >From 6154b784240703f2b7be1aa05c2b813aa2511435 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Fri, 29 Apr 2022 18:41:08 +0100 Subject: [PATCH] don't mask out std::string Change-Id: Ief1da58246b859228fbe318d514cb9ce34629990 --- gdb/cp-support.c | 3 ++- gdb/testsuite/gdb.cp/no-dmgl-verbose.cc | 5 +++++ gdb/testsuite/gdb.cp/no-dmgl-verbose.exp | 4 ++-- 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/gdb/cp-support.c b/gdb/cp-support.c index f52055893d2..78c302abaef 100644 --- a/gdb/cp-support.c +++ b/gdb/cp-support.c @@ -146,13 +146,14 @@ inspect_type (struct demangle_parse_info *info, memcpy (name, ret_comp->u.s_name.s, ret_comp->u.s_name.len); name[ret_comp->u.s_name.len] = '\0'; +#if 0 /* Ignore any typedefs that should not be substituted. */ for (const char *ignorable : ignore_typedefs) { if (strcmp (name, ignorable) == 0) return 0; } - +#endif sym = NULL; try diff --git a/gdb/testsuite/gdb.cp/no-dmgl-verbose.cc b/gdb/testsuite/gdb.cp/no-dmgl-verbose.cc index 454ab4c42ea..d9a666f2c48 100644 --- a/gdb/testsuite/gdb.cp/no-dmgl-verbose.cc +++ b/gdb/testsuite/gdb.cp/no-dmgl-verbose.cc @@ -21,3 +21,8 @@ void f (std::string s) { } + +int +main () +{ +} diff --git a/gdb/testsuite/gdb.cp/no-dmgl-verbose.exp b/gdb/testsuite/gdb.cp/no-dmgl-verbose.exp index 14f11ddcf04..c54daf33c8b 100644 --- a/gdb/testsuite/gdb.cp/no-dmgl-verbose.exp +++ b/gdb/testsuite/gdb.cp/no-dmgl-verbose.exp @@ -19,12 +19,12 @@ standard_testfile .cc if { [skip_cplus_tests] } { continue } -if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}.o" object {c++ debug}] != "" } { +if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {c++ debug}] != "" } { untested "failed to compile" return -1 } -clean_restart ${testfile}.o +clean_restart ${testfile} gdb_test_no_output "set breakpoint pending off" base-commit: 225170409b47bc96b62b2ecfcc0d9d5ae1ef8949 prerequisite-patch-id: be6afcdb35fd6ed141be7d568afbcd1ae4f082ee prerequisite-patch-id: be2d0109aea479ee1973cf5b6d6454b5811cfce4 -- 2.36.0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ So that seems like something that should be fixed in GDB, somehow. Now, I'm wondering what is it that DMGL_VERBOSE outputs differently than not having it. The full name of std::string in libstd++ is nowadays: "std::__cxx11::basic_string, std::allocator >", and the only difference compared to what we have in the test is the __cxx11 namespace, which has meanwhile been added for the new C++11 ABI. Here's today, vs testcase's, with extra space added for alignment: today: "std::__cxx11::basic_string, std::allocator >" test: "std:: basic_string, std::allocator >" Hmm. If I force the testcase to use the old ABI to emulate what was being seeing back then, with: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git c/gdb/testsuite/gdb.cp/no-dmgl-verbose.exp w/gdb/testsuite/gdb.cp/no-dmgl-verbose.exp index c54daf33c8b..4718191b471 100644 --- c/gdb/testsuite/gdb.cp/no-dmgl-verbose.exp +++ w/gdb/testsuite/gdb.cp/no-dmgl-verbose.exp @@ -19,7 +19,7 @@ standard_testfile .cc if { [skip_cplus_tests] } { continue } -if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {c++ debug}] != "" } { +if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {c++ debug additional_flags=-D_GLIBCXX_USE_CXX11_ABI=0}] != "" } { untested "failed to compile" return -1 } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I'd expect that the breakpoint at the non-typedef'd name, like in: gdb_test {break 'f(std::basic_string, std::allocator >)'} \ {Function ".*" not defined\.} \ "DMGL_VERBOSE-demangled f(std::string) is not defined" ... would actually manage to be set, and thus that test would fail. Obviously it didn't back then. But why? Turns out that with the old ABI we get this mangled name for the function: $ nm -A testsuite/outputs/gdb.cp/no-dmgl-verbose/no-dmgl-verbose |grep _Z testsuite/outputs/gdb.cp/no-dmgl-verbose/no-dmgl-verbose:0000000000001129 T _Z1fSs and running through c++filt does give us: $ echo _Z1fSs | c++filt f(std::basic_string, std::allocator >) which is the demangled name Jan used in the test. Interestingly, _Z1fSs seems very short. That "S" seems like a shortcut for std::string. Here's what the mangled name looks like WITHOUT -D_GLIBCXX_USE_CXX11_ABI=0, thus with modern ABI: testsuite/outputs/gdb.cp/no-dmgl-verbose/no-dmgl-verbose:0000000000001129 T _Z1fNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE If I run the gdb.cp/no-dmgl-verbose.exp test with -D_GLIBCXX_USE_CXX11_ABI=0, plus the hack in cp-support.c to disable the std::string typedef thing, the breakpoint at f(std::string) surprisingly fails again! (gdb) PASS: gdb.cp/no-dmgl-verbose.exp: set breakpoint pending off break 'f(std::string)' Function "f(std::string)" not defined. (gdb) FAIL: gdb.cp/no-dmgl-verbose.exp: gdb_breakpoint: set breakpoint at 'f(std::string)' break 'f(std::basic_string, std::allocator >)' Function "f(std::basic_string, std::allocator >)" not defined. (gdb) PASS: gdb.cp/no-dmgl-verbose.exp: DMGL_VERBOSE-demangled f(std::string) is not defined But note, if I debug it manually, I see this: (gdb) b f( [TAB] (gdb) b f( std::string) Ah! That's different with the modern ABI, where TAB completion gives you the whole full basic_string non-typedefed name. Ah! That's because GDB demangles the old ABI's _Z1fSs as f(std::string): (gdb) demangle _Z1fSs f(std::string) (gdb) demangle _Z1fNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE f(std::__cxx11::basic_string, std::allocator >) And note this: $ echo "_Z1fSs" | c++filt f(std::basic_string, std::allocator >) $ echo "_Z1fSs" | c++filt --no-verbose f(std::string) Bingo. c++filt uses DMGL_VERBOSE by default, unless you pass it --no-verbose. I don't know why the test would fail if I force the old ABI, and I hack out the std::string typedef replacement stuff in cp-support.c. That's weird. And now the fun thing -- reverting the cp-support.c hack, and just adding the -D_GLIBCXX_USE_CXX11_ABI=0 makes the testcase behave like it used to when it was written, and it passes cleanly for me, as below. GDB should be fixed so that setting a breakpoint at "f(std::string)" should work with new ABI too, but that can be a separate thing. >From 4a9a9b0bcff56254b7897a3820bc06d9987aeac3 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Fri, 29 Apr 2022 19:28:13 +0100 Subject: [PATCH] Fix gdb.cp/no-dmgl-verbose.exp Change-Id: I196568fd92c2a6747a0467f12510714f549be2b7 --- gdb/testsuite/gdb.cp/no-dmgl-verbose.exp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/testsuite/gdb.cp/no-dmgl-verbose.exp b/gdb/testsuite/gdb.cp/no-dmgl-verbose.exp index 14f11ddcf04..fd4e56f40b4 100644 --- a/gdb/testsuite/gdb.cp/no-dmgl-verbose.exp +++ b/gdb/testsuite/gdb.cp/no-dmgl-verbose.exp @@ -19,7 +19,7 @@ standard_testfile .cc if { [skip_cplus_tests] } { continue } -if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}.o" object {c++ debug}] != "" } { +if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}.o" object {c++ debug additional_flags=-D_GLIBCXX_USE_CXX11_ABI=0}] != "" } { untested "failed to compile" return -1 } -- 2.36.0