From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74001 invoked by alias); 4 Mar 2018 04:28:22 -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 73974 invoked by uid 89); 4 Mar 2018 04:28:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Received:10.99.111.137, H*c:alternative, hundreds X-HELO: mail-pg0-f44.google.com Received: from mail-pg0-f44.google.com (HELO mail-pg0-f44.google.com) (74.125.83.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 04 Mar 2018 04:28:17 +0000 Received: by mail-pg0-f44.google.com with SMTP id l131so5475293pga.2 for ; Sat, 03 Mar 2018 20:28:17 -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=U9SisJ5vHMeCb5XdNzCZuHZGo/W3RDaeSf5H8tduO88=; b=fjIdqhjZi+il/RPJmSM5zz8tlF0B6Y2baJEBnRUYjcQQuntjDsrDcViamf7Jtg0i8y QkQ8YzukpXw875llV7yJQVcjC53VsQotkQJI4np7qqoKOfNtRbrPZzNQlG7YTRxhhhqJ TBUO3uUKRKpBxap9z08P2mtTB4qNRxh82HOSl11n6HBEoF/0BMIrqFHL5SDz/ct4RHb6 c9xuctidtthXnRmHNudsZj1QRBEy1Oa3aCnz0Wutxv8fbKHgSa0mz5jgVaMCzMkSDe2x vU+qDFoDgbWatUQoNeQuUSVve1YJmTEhj77ICFJMYo7Outgy976Y7KB5fYBpwpRjezZQ h+Iw== X-Gm-Message-State: APf1xPDbTl8xkOifl/Fw3E1YI3UAgKoMtVYwwrIVh0CEatPVQU0OVJ9I IixvFUOL45TFkekyOlt/x9kwGP2eaO4LYh5mL3/+8A== X-Google-Smtp-Source: AG47ELsWfufUwaDewsUggLCc2ekdaaidJnl4cjOFqpgH4bGyn7bNx3LSwR/Z9t+uRNHHxCkjH7a4yH5YbaqdFIFAq88= X-Received: by 10.99.111.137 with SMTP id k131mr8873179pgc.11.1520137695444; Sat, 03 Mar 2018 20:28:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.181.4 with HTTP; Sat, 3 Mar 2018 20:28:14 -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: Daniel Berlin Date: Sun, 04 Mar 2018 04:28:00 -0000 Message-ID: Subject: Re: gdb 8.x - g++ 7.x compatibility To: Roman Popov Cc: Jason Merrill , 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/msg00010.txt.bz2 Again, please don't do this. As you can see (see Tom Tromey's email), others have a use to go between vtable types and the types they are attached to. We should be getting away from linkage names, not going further towards them. There are a bunch of gdb bugs this won't solve, but adding an extension (like tom did for rust) to go between vtable types and concrete types will solve *all* of them, be *much faster* than what gdb does now, and have basically *no* space increase at all. Meanwhile, i can hand you binaries where the size increase is in the hundreds of megabytes to gigabytes for adding linkage names. On Fri, Mar 2, 2018 at 3:06 PM, Roman Popov wrote: > 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 > > >