From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55268 invoked by alias); 6 Feb 2018 03:52:34 -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 55228 invoked by uid 89); 6 Feb 2018 03:52:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=providers, H*i:sk:a1b77cd, talk X-HELO: mail-oi0-f47.google.com Received: from mail-oi0-f47.google.com (HELO mail-oi0-f47.google.com) (209.85.218.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 06 Feb 2018 03:52:32 +0000 Received: by mail-oi0-f47.google.com with SMTP id t78so381334oih.4 for ; Mon, 05 Feb 2018 19:52:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GbKLOSrCZKFHBuLO2sSY3L8dnaw62jekJuhop8JVeKo=; b=FWBrOt3zgPnEpDWnvahzNNO1+TLdf2KdubOxoWADM9dbAcozbKvTM1aRNHxFgkpGbh jKTYcD7yhhRf5NOhG7SoIngccXoCAz6+ujcN6I1VaGjkj17mPza12poi8LqUo406s1v2 BneuRQlgg/+n/L5OZAD0gwtcIvB7uumNWL0WoLXI8F/iYt8wyP/APeaZA+hsuxEvykAo y+HgYbQ7EZhPy+F90glgrMqiEPUiydnA2IDoassCtMTiLKZCM2Nw1Mm5ip4iuBf8K3oO i2YKyCAcI4O447JmDE59GrXxXJP7p6Z92BGIrhS/1BhghYE4/Drppds5HTfHn+B4Asuc GX0Q== X-Gm-Message-State: APf1xPDlgqFrFxb5+W8uNeE+eBCUyk1s+TvloC7ScEcAPaMo8ZabVLhp yQe92elh08kYhsMQiJ+Dbdx/fg== X-Google-Smtp-Source: AH8x225/ECQQPwcnVbTfzC4i0LCw1CqSL2Yw3dBpmHopTh6J8XFsbSFoHHz813Kdg7le3+JF8M0BQQ== X-Received: by 10.202.232.21 with SMTP id f21mr574901oih.29.1517889150578; Mon, 05 Feb 2018 19:52:30 -0800 (PST) Received: from localhost.localdomain (75-171-255-194.hlrn.qwest.net. [75.171.255.194]) by smtp.gmail.com with ESMTPSA id u37sm5093207otc.34.2018.02.05.19.52.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Feb 2018 19:52:29 -0800 (PST) Subject: Re: gdb 8.x - g++ 7.x compatibility To: Simon Marchi 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> Cc: Manfred , gdb@sourceware.org, gcc@gcc.gnu.org From: Martin Sebor Message-ID: Date: Tue, 06 Feb 2018 03:52:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-02/txt/msg00043.txt.bz2 On 02/05/2018 09:59 AM, Simon Marchi wrote: > On 2018-02-05 11:45, Martin Sebor wrote: >> Yes, with auto, the type of the constant does determine the type >> of the specialization of the template in the source code. >> >> In non-type template arguments, and more to the point I was making, >> in diagnostics, the suffix shouldn't or doesn't need to be what >> distinguishes the type of the template, even with auto. The part >> "with auto IVAL = 10" in the message >> >> 'void foo::print() [with auto IVAL = 10]': >> >> would be far clearer if auto were replaced by the deduced type, >> say along these lines: >> >> 'void foo::print() [with int IVAL = 10]': >> >> rather than relying on the suffix alone to distinguish between >> different specializations of the template. That seems far too >> subtle to me. But I think the diagnostic format is (or should >> be) independent of the debug info. > > That makes sense. > >> With respect to the suffix, I keep coming back to the reality >> that even if GCC were to change to emit a format that GDB can >> interpret easily and efficiently, there still are other >> compilers that emit a different format. So the conclusion >> that a general solution that handles more than just one format >> (at least for non-type template arguments without auto) seems >> unescapable. > > If there are other compilers we wanted to support for which we can't > trust the template format, we could always ignore the template part of > DW_AT_name specifically for them. But since g++ and gdb are part of the > same project and are expected to work well and efficiently together, I > would have hoped that we could agree on a format so that gdb would not > have to do the extra work when parsing a g++-generated file > (consequently the same format that libiberty's demangler produces). > > Given the problem I illustrated in my previous mail, I don't have a > general solution to the problem to propose. Okay, let me talk to Jason to see what he thinks. I'm open to restoring the suffix for the debug info as long as it doesn't adversely affect the diagnostics. I agree that if GCC can help make GDB more efficient it's worth putting effort into. (I do still think that GDB should work with other providers besides GCC, even if perhaps not necessarily as efficiently.) Martin