From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 258A7393BC11 for ; Tue, 13 Apr 2021 08:57:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 258A7393BC11 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 44DF4ABB3; Tue, 13 Apr 2021 08:57:28 +0000 (UTC) Subject: Re: Expected output of gdb.cp/no-dmgl-verbose.exp To: Luis Machado , Keith Seitz , "gdb@sourceware.org" References: <3de907e5-c711-ab80-8b27-f7c13fbde7ec@linaro.org> <39eb19e5-d1fd-4997-60e0-e9835fd1d090@redhat.com> <5cdfc7cf-5c94-c8b9-8cd2-2747085a7b42@linaro.org> From: Tom de Vries Message-ID: <6230acdf-994a-8d69-d388-6e03062fe301@suse.de> Date: Tue, 13 Apr 2021 10:57:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <5cdfc7cf-5c94-c8b9-8cd2-2747085a7b42@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 08:57:30 -0000 On 4/12/21 8:55 PM, Luis Machado via Gdb wrote: > On 4/12/21 3:45 PM, Keith Seitz wrote: >> On 4/12/21 11:16 AM, Luis Machado via Gdb wrote: >>> I'm trying to determine why this particular test is failing (for both >>> aarch64-linux and x86_64-linux on Ubuntu 18.04/20.04) and what the >>> expected outcome is. >>> >>> In my case, the only symbol I see for function "f" is the following: >>> >>> "f(std::__cxx11::basic_string, >>> std::allocator >)" >>> >>> There is no "f(std::string)" nor "f(std::basic_string>> std::char_traits, std::allocator >)" symbol. >>> >> >> Wow, such a long time ago! IIRC... > > Indeed. I vaguely remember that, back in ~2011 IIRC. But obviously not > enough to figure out what was going on. > >> >> This test was written to ensure that "std::string" was used >> instead of "std::basic_string<...>" (which is now called something >> else again). Something about "that's what nm and other tools tell users, >> so we should not mention the symbol's real (linkage) name, either." >> >> The "no-dmgl-verbose" refers to the DMGL_VERBOSE option >> of the demangler, which does this. >> >> There is even special logic in our typedef-replacing machinery to >> enforce this. [NOTE: `ignore_typedefs' in cp-support.c is also "out- >> of-date" wrt to this naming change. So none of that has likely been >> "working" for many years, but then at very quick glance, "nm -C" doesn't >> do this anymore, either.] > > Ah, that makes it much more clear. Thanks for the explanation. > >> >> I was against it then, so I certainly do not mind getting rid of this >> test >> or limiting it to C++ installations that typedef the "older" >> std::basic_string<...> >> to std::string. > > I think keeping it may be more confusing than useful. I'll propose its > removal on gdb-patches@ and we'll see where we go from there. > The FAIL was mentioned here: https://sourceware.org/bugzilla/show_bug.cgi?id=19436#c7 Thanks, - Tom