From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17136 invoked by alias); 7 Feb 2018 17:11:15 -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 17036 invoked by uid 89); 7 Feb 2018 17:11:14 -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*i:sk:7XgiOw1, H*r:sk:o13-v6s, H*f:sk:7XgiOw1 X-HELO: mail-pl0-f42.google.com Received: from mail-pl0-f42.google.com (HELO mail-pl0-f42.google.com) (209.85.160.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Feb 2018 17:11:07 +0000 Received: by mail-pl0-f42.google.com with SMTP id o13-v6so398181pli.6 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=ZLz4aikXN/tTakkMwHa6JZDzTL7/XdF81TNpSl7QyGz6MZQw2kJfOto+/npWf3cePA ZBxpK9fP1r5HzLkAGRtQ2OFgf7OoBDEBLzZJtWUb70GerBdXcUyIybxsdpdq96ZPxvSZ tfZQXN7uQL6NA/9S85UV3QVl+hRCE7j+IXHP0Scqn9g3r8/hpVUZsZlAM99q+b75weLC 2wQSpQmavXCPd4R1BTeRwlu7IsTNp8FLiDEOpmSEGPG8TTOs7P1VqlIvF9p2NH9JH4mC uHO9l4dNEfodH+dX53JtVgD/kBPPORrWHsZFYz1u4orSBb6qlr8coXhQ2Gtu3aJsRbTu ctCA== X-Gm-Message-State: APf1xPBqb/xR3MJNZF/zeaGEChE6/gubpAAAbv1ONBrXKRxKeXqlJs0I dJSd9AyYPXowk0rEfxeJ22zCRgnHGBNC74LRuCMGpQ== 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/msg00066.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.