From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16235 invoked by alias); 7 Feb 2018 17:11:09 -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 16215 invoked by uid 89); 7 Feb 2018 17:11:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.1 required=5.0 tests=BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=lasted, H*r:sk:f4-v6so, H*i:sk:7XgiOw1, H*f:sk:7XgiOw1 X-HELO: mail-pl0-f54.google.com Received: from mail-pl0-f54.google.com (HELO mail-pl0-f54.google.com) (209.85.160.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Feb 2018 17:11:07 +0000 Received: by mail-pl0-f54.google.com with SMTP id f4-v6so389853plr.10 for ; Wed, 07 Feb 2018 09:11:07 -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=AzYpDAxdd+kEu72VUEDP3bPa1Cx51sTZrxcNplTpjCo=; b=uS1i/vXEfocwperTZXwJrRCMB6u+62yfIReP66iafByFBHB2b2WNApP5VGh/D9M/mZ wAiIbxb/QPwkgQW6M4Mvo0/aXFfe3e/aoBebWCBj2fN4fTWerS2Rr3bKTKsPwm2IKR4U K26evXLy1MFkK5XjYsFCmG4fNW2HAPHE1tfwSFbnKB2OWb9c+oZ1YJJeVAm/gpnZDqV+ 8c9uV7jzTJoVorwobBMJnOk13f3IXdS+dHJQzq+lyxmYBonfWrWyo9vOLf65I1NpJNCv G+WZNya78veWDYX62Mu+MMiiNHsxDWG8qc7asBFS4IHsO+JwOL9yP0NzSDn4XQo7XxGQ RcHA== X-Gm-Message-State: APf1xPDOKBDomw4H2zSzPhuz2riwZc7aXS31TdJuwp3iCe2Fdkyf3uOw 6Cq1i/QIhq2/U1WF2WfJLJ3lVR+YU9is2yt/dDQNsg== X-Google-Smtp-Source: AH8x2250MChPyNwxVg7O6TOJB9tdSJ2BevEVebp5Kxx9TzZUhWATP1hvojMKfOfJD5PAngbz0u9q9tU8vvBlHZQsQGg= X-Received: by 2002:a17:902:b610:: with SMTP id b16-v6mr6644666pls.132.1518023466112; Wed, 07 Feb 2018 09:11:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.148.198 with HTTP; Wed, 7 Feb 2018 09:11:05 -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> <6da16f7c-4801-4c57-2197-271db491a88f@gmail.com> <6394368bca446f08119118a0f88a30b7@polymtl.ca> From: Daniel Berlin Date: Wed, 07 Feb 2018 17:11:00 -0000 Message-ID: Subject: Re: gdb 8.x - g++ 7.x compatibility To: Simon Marchi Cc: Martin Sebor , Manfred , gdb@sourceware.org, GCC Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-02/txt/msg00078.txt.bz2 > > > This avoids the problem of the demangler gdb is using getting a different > name than the producer used. It also should always give you the right one. > If the producer calls the type "vtable fo Foo<2u>" here and "Foo<2>" > elsewhere, yes, that's a bug. It should be consistent. > > This should be Foo<2u> vs Foo<2> > If there are multiple types named Foo<2u>, DWARF needs to be extended to > allow a pointer from the vtable debug info to the class type debug info > (unless they already added one). > Then you would do *no* symbol lookups, you'd follow that pointer (gdb > would add it to the symbol_info structure) > Note that the ABI is explicitly designed so that type identity can be done by address comparison. Also note that adding alternative names for symbols is probably a "not great" idea, though it would work. The *vast* majority of debug info is in those names, and adding long names will often triple or quadruple the size of debug info. Google has binaries where 90% of the size is in gigabytes of linkage names. People have worked hard to need the names *less*. So you want to get *away* from going by name, especially when the compiler knows "this is the vtable that goes with this type". It should just tell you. Right now, that is what you are missing "given a vtable for a type, how do i get the type". Trying to do that by name is a hack. A hack that has lasted 15+ years mind you, but still a hack. I would just kill that hack.