From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37764 invoked by alias); 3 Mar 2018 04:01:17 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 37740 invoked by uid 89); 3 Mar 2018 04:01:16 -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,FREEMAIL_FROM,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*c:alternative X-HELO: mail-lf0-f44.google.com Received: from mail-lf0-f44.google.com (HELO mail-lf0-f44.google.com) (209.85.215.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 03 Mar 2018 04:01:14 +0000 Received: by mail-lf0-f44.google.com with SMTP id l191so16009112lfe.1 for ; Fri, 02 Mar 2018 20:01:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hvfEq4zj3sBiz+Rayp8DrSnkrNPdbhSvyoRvXnDqHiU=; b=UCLOJgkSLuA+A8YtAiFXKnwEqcN509FxgaVVnMM97KAvExT/8fpYRf8XneGcvGWNvk +QdOIHCk8YvvTUNTYojyVRJGC77l2u5ER3tplEl2yukTeR7+FyvYyCsoDT8gaZDD7n89 Pbw/euxQX3JK/KDHm2sWyGdKHx1fI1KAMQs5jrMOgubxr68xsM+xDNPsd9kGOMHyvnFk jXxe4szaAkVMiuEcak2hguYeS9VyIAOR6cZjPIpDP67Q3D+LXCmKGAHxIoC8EQurBpww qsSaQP6h+gbmOjul4xSrDmiTOhlKm+ch9xSMWlpyGj7WbVhjHgNPe4JwuN9j+B9aLjIQ lFFQ== X-Gm-Message-State: AElRT7GPF6kNsFZXveQt3UHtdvjSuPf3e7N/Mb13CnBGF7/1btXlv6Fr h2xJ98VaRCy7K+TVINameUXtYIQQa+U2z3AT2XI= X-Google-Smtp-Source: AG47ELug7myZczoVJnNfGm4EF1pQtJk92bClUCn53zKshOh+Z1/YU1tJa2FdDiwQUynclVzOe9pYInRG4kURf/6dAmc= X-Received: by 10.25.208.196 with SMTP id h187mr2623343lfg.107.1520049672137; Fri, 02 Mar 2018 20:01:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.62.7 with HTTP; Fri, 2 Mar 2018 20:01:11 -0800 (PST) In-Reply-To: References: <1517667601.3405.123.camel@gnu.org> <1b58e2df-5425-4f22-510c-d2e9f51040ba@polymtl.ca> <39845077-6bdf-f60d-9bfc-a491e7fa4fc7@gmail.com> <132fbd97-4f0d-020f-1c0f-1d4097800233@polymtl.ca> From: Roman Popov Date: Sat, 03 Mar 2018 04:01:00 -0000 Message-ID: Subject: Re: gdb 8.x - g++ 7.x compatibility To: Jason Merrill Cc: Andrew Pinski , Richard Biener , Simon Marchi , Martin Sebor , Manfred , GDB Development , GCC Development Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-03/txt/msg00020.txt.bz2 I've experimented with adding DW_AT_linkage_name for composite types in LLVM. Here is impact on binary sizes (compiled with debuginfo): Original size with DW_AT_linkage_name for composites % increase clang-7.0 1926574256 1952846192 1.4% clang-tidy 1220980360 1238498112 1.4% llvm-mt 7404728 7525328 1.6% cout<<"hello"; 21552 22080 2.4% -Roman 2018-03-02 15:06 GMT-08:00 Roman Popov : > Ok, sounds reasonable. In case of debugger we are indeed "linking" RTTI > name with name in debuginfo. > > I've checked LLVM docs, they generate Debuginfo from LLVM "Metadata", and > metadata for types already contains mangled names in "identifier" field: > https://llvm.org/docs/LangRef.html#dicompositetype . So it should not be > hard to propagate it to object file. > > I will ask on LLVM maillist if they can emit it. > > > 2018-03-01 13:03 GMT-08:00 Jason Merrill : > >> On Thu, Mar 1, 2018 at 3:26 PM, Andrew Pinski wrote: >> > On Thu, Mar 1, 2018 at 12:18 PM, Roman Popov wrote: >> >> Is there any progress on this problem? >> >> >> >> I'm not familiar with G++ , but I have little experience with LLVM. I >> can >> >> try make LLVM emitting mangled names to DW_AT_name, instead of >> demangled >> >> ones. >> >> This way GDB can match DW_AT_name against RTTI. And for display it can >> >> call abi::__cxa_demangle(name, NULL, NULL, &status), from #include >> >> . >> >> >> >> Will it work? >> > >> > >> > Reading http://wiki.dwarfstd.org/index.php?title=Best_Practices: >> > the DW_AT_name attribute should contain the name of the corresponding >> > program object as it appears in the source code, without any >> > qualifiers such as namespaces, containing classes, or modules (see >> > Section 2.15). A consumer can easily reconstruct the fully-qualified >> > name from the DIE hierarchy. In general, the value of DW_AT_name >> > should be such that a fully-qualified name constructed from the >> > DW_AT_name attributes of the object and its containing objects will >> > uniquely represent that object in a form natural to the source >> > language. >> > >> > >> > So having the mangled symbol in DW_AT_name seems backwards and not the >> > point of it. >> >> If we add the mangled name, which seems reasonable, it should be in >> DW_AT_linkage_name. >> >> Jason >> > >