From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52782 invoked by alias); 8 Feb 2018 14:05:20 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 52697 invoked by uid 89); 8 Feb 2018 14:05:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 spammy= X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Feb 2018 14:05:18 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ejmp8-0005Ku-50 for gdb@sourceware.org; Thu, 08 Feb 2018 09:05:17 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55500) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ejmp8-0005Ko-0Z for gdb@sourceware.org; Thu, 08 Feb 2018 09:05:14 -0500 Received: from pool-74-104-137-100.bstnma.fios.verizon.net ([74.104.137.100]:55554 helo=homebase) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ejmp7-0000Qo-II; Thu, 08 Feb 2018 09:05:13 -0500 Message-ID: <1518098712.3405.274.camel@gnu.org> Subject: Re: gdb 8.x - g++ 7.x compatibility From: Paul Smith Reply-To: psmith@gnu.org To: gdb@sourceware.org, GCC Date: Thu, 08 Feb 2018 14:05:00 -0000 In-Reply-To: References: <1b58e2df-5425-4f22-510c-d2e9f51040ba@polymtl.ca> <39845077-6bdf-f60d-9bfc-a491e7fa4fc7@gmail.com> <132fbd97-4f0d-020f-1c0f-1d4097800233@polymtl.ca> <6da16f7c-4801-4c57-2197-271db491a88f@gmail.com> <6394368bca446f08119118a0f88a30b7@polymtl.ca> <0f519031e0a603b18788589d5c1700d3@polymtl.ca> <5a58deaaf993c5dc275386e5cd89cc37@polymtl.ca> <77ac6b1d9e32784761e05424604f58d5@polymtl.ca> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00075.txt.bz2 On Thu, 2018-02-08 at 11:26 +0000, Michael Matz wrote: > As I said upthread, the mangled name of a type (sans _Z prefix) is what is > stored as the type name for RTTI purposes (i.e. std::type_info::name()). > > It's just that the debug info currently doesn't have any reference to that > definitely-unique string, only to the "human-friendly" name, which > somewhat resembles the demangled name (and that's exactly the crux, it > really isn't the demangled one right now, as you found out the painful > way). Isn't the problem with the mangled name, which otherwise would be just what we wanted since it's easy to match and is unique in just the way we want it to be, that mangling is not standardized? If GDB relied on the mangled name it would need to incorporate demanglers for any compiler that it wanted to be able to debug and figure out which demangler to use when it was trying to debug a program. This goes against the concept of a common debug format like DWARF I would expect.