From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id 1DFE2382E832 for ; Mon, 12 Apr 2021 20:08:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1DFE2382E832 Received: by mail-pf1-x433.google.com with SMTP id o123so9908600pfb.4 for ; Mon, 12 Apr 2021 13:08:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WMWaNJLARrh2hplga44lKihpw9ffBfScWUOUTaAu1vg=; b=JuowSvV8AQ6rYAToNsMCQqjOyBfwZwH8yFHH30SaxqfR8WYsybTUW0jR9EHzK+LLlZ XFkY0J0VykmAVujoIF6W3sLre21XNSFm9xaGxPLC2l/6JXx7uL8nR5RT4R5Ij4Ta+TK7 HXHUDIkzTRgjA4JXFuhkxrpsIdLxZat3gK7uik6imBJJN76ix80P6pa8DWRtQUyXTzcb 81/HYhRXXastunGw7d12zbWfzZGWdMtsBS1G+nNoWvfOwXYNhjcWj1Zwap2nQvaP6bTf ll+tA28Z6NKJKIALDqPNdxt5TAvc9xb6N9IbtuMNxF0CHQFzD+C7pc8cRZy+XhchQ7na RFXg== X-Gm-Message-State: AOAM530gGkpoyk3u7PW4t5Kehtv8IQ/Q3QBd6KjSZtOoHMv1iDX3QwD6 rXCulTNJ8b+GK6ftp8YaeRWURcsnXRmlHnQazU0= X-Google-Smtp-Source: ABdhPJzBtrNBiH+m68vYqhj1ni88sBJqeQbap9cj42/ao+0eaHuN0cUDQMhzYRHmDCRvDDqc+AN31r1kvCsyt0ZtJO0= X-Received: by 2002:a63:4c0e:: with SMTP id z14mr28595504pga.30.1618258083213; Mon, 12 Apr 2021 13:08:03 -0700 (PDT) MIME-Version: 1.0 References: <3de907e5-c711-ab80-8b27-f7c13fbde7ec@linaro.org> <39eb19e5-d1fd-4997-60e0-e9835fd1d090@redhat.com> <5cdfc7cf-5c94-c8b9-8cd2-2747085a7b42@linaro.org> In-Reply-To: <5cdfc7cf-5c94-c8b9-8cd2-2747085a7b42@linaro.org> From: David Blaikie Date: Mon, 12 Apr 2021 13:07:52 -0700 Message-ID: Subject: Re: Expected output of gdb.cp/no-dmgl-verbose.exp To: Luis Machado Cc: Keith Seitz , "gdb@sourceware.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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: Mon, 12 Apr 2021 20:08:05 -0000 FWIW - at least some Clang folks are working on adding a "preferred_name" attribute ( https://reviews.llvm.org/D91311 ) which would be used to help tools understand that std::basic_string 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. > > Thanks Keith. > > > > > Keith > >