From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80173 invoked by alias); 7 Feb 2018 20:29:41 -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 80137 invoked by uid 89); 7 Feb 2018 20:29:41 -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,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=unavailable version=3.3.2 spammy=associates, H*f:sk:7XgiOw1, H*i:sk:7XgiOw1, solid X-HELO: gateway20.websitewelcome.com Received: from gateway20.websitewelcome.com (HELO gateway20.websitewelcome.com) (192.185.49.40) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Feb 2018 20:29:38 +0000 Received: from cm16.websitewelcome.com (cm16.websitewelcome.com [100.42.49.19]) by gateway20.websitewelcome.com (Postfix) with ESMTP id 196A3401113CD for ; Wed, 7 Feb 2018 14:29:37 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id jWLYeatYhODN4jWLYeUxfC; Wed, 07 Feb 2018 14:29:37 -0600 Received: from 174-29-33-254.hlrn.qwest.net ([174.29.33.254]:54136 helo=pokyo) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ejWLY-002TR5-Gf; Wed, 07 Feb 2018 14:29:36 -0600 From: Tom Tromey To: Daniel Berlin Cc: Simon Marchi , Martin Sebor , Manfred , gdb@sourceware.org, GCC Subject: Re: gdb 8.x - g++ 7.x compatibility 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> Date: Wed, 07 Feb 2018 20:29:00 -0000 In-Reply-To: (Daniel Berlin's message of "Wed, 7 Feb 2018 09:04:04 -0800") Message-ID: <87vaf8wnkg.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BWhitelist: no X-Source-L: No X-Exim-ID: 1ejWLY-002TR5-Gf X-Source-Sender: 174-29-33-254.hlrn.qwest.net (pokyo) [174.29.33.254]:54136 X-Source-Auth: tom+tromey.com X-Email-Count: 6 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-SW-Source: 2018-02/txt/msg00072.txt.bz2 >>>>> "Dan" == Daniel Berlin writes: Dan> If there are multiple types named Foo<2u>, DWARF needs to be extended to Dan> allow a pointer from the vtable debug info to the class type debug info Dan> (unless they already added one). This is what we did for Rust. Rust doesn't have a stable ABI yet, so using gdb's current approach -- having the debugger use details of the ABI in addition to the debug info -- wasn't an option. So, instead, the Rust compiler emits DWARF for the vtable and associates the vtable with the concrete type for which it was emitted. This required a minor DWARF extension. I think C++ could probably do something along these lines as well. The current gdb approach hasn't been really solid since function-local classes were added to C++. IIRC there are bugs in gdb bugzilla about this. These kinds of problems are, I think, completely avoided by a DWARF-based approach. Tom