From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112137 invoked by alias); 5 Feb 2018 17:44:43 -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 112116 invoked by uid 89); 5 Feb 2018 17:44:42 -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,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=H*f:sk:a1b77cd, H*i:sk:a1b77cd, H*c:alternative X-HELO: mail-wm0-f67.google.com Received: from mail-wm0-f67.google.com (HELO mail-wm0-f67.google.com) (74.125.82.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 05 Feb 2018 17:44:40 +0000 Received: by mail-wm0-f67.google.com with SMTP id r71so27892102wmd.1 for ; Mon, 05 Feb 2018 09:44:40 -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=vPVHGg1i2VHrgYyXiv2SBeHb4ohYCHWxpPVZmLFa+Kc=; b=cpVbGB6LUAxDhcH/aWP6H3xsc7f9EGyPSqh2IhBmsVdLVKEhhe31aLU3NTyIL53C1f CNQArZqRpOHNwYXhZhq6cc4K1M9Ya+UW+GsKxCA8yHHTx23/3y/sXWZYx2KkrJBUBZBe CAM6zleTqWzVDcLIW5+QvZ1lBz2xDXya53fya+NoB1d0YRQXpWimeFbNuBy5Q8tyzFkQ CxrXxC2hkZT28ZDVWfKWqhRODb9ZU2BFbD0JUpG8DIYUUeCAjuQZXvM2UrSnCcWnMyHO VTwIEGRWohsEpLAe/km25JKUBpJxFCCVXpa1/JVVG8NEsN8OQ+lYi11WZhpiCj9ConsX cTKg== X-Gm-Message-State: APf1xPCUnDxCNVOXj5Dwv4gSC8RSy2piWig/RTcgu1GKR4HudIJeoejh KfDpZhZm2+aIgwVz1Qn8j8STbuitGq+ox5SscLc= X-Google-Smtp-Source: AH8x227RFYWkVK/yaYHwtsi+bF8Ihfxey7VFXVn5AeEj8WUnc2E9pZu0ezuSjmvgP2/RNMVfB5vzL9NAFD23Ok1FPSc= X-Received: by 10.28.185.196 with SMTP id j187mr119369wmf.94.1517852678729; Mon, 05 Feb 2018 09:44:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.122.19 with HTTP; Mon, 5 Feb 2018 09:44:38 -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> From: Roman Popov Date: Mon, 05 Feb 2018 17:44:00 -0000 Message-ID: Subject: Re: gdb 8.x - g++ 7.x compatibility To: Simon Marchi Cc: Martin Sebor , Manfred , gdb@sourceware.org, gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00030.txt.bz2 Interestingly RTTI name also gives no guarantees: http://en.cppreference.com/w/cpp/types/type_info/name << Returns an implementation defined null-terminated character string containing the name of the type. No guarantees are given; in particular, the returned string can be identical for several types and change between invocations of the same program. >> It probably makes sense to look how g++ implements std::type_info::operator== . Probably there are some hints that GDB algorithm can utilize. Operator std::type_info::operator== must return true for equivalent types. 2018-02-05 8:59 GMT-08:00 Simon Marchi : > 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. > > Simon >