From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14093 invoked by alias); 29 Jan 2018 15:33:07 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 14081 invoked by uid 89); 29 Jan 2018 15:33:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=letting X-HELO: mail-wm0-f48.google.com Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Jan 2018 15:33:05 +0000 Received: by mail-wm0-f48.google.com with SMTP id t74so15155281wme.3 for ; Mon, 29 Jan 2018 07:33:04 -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-language :content-transfer-encoding; bh=kuMFnubIt4LKvAzmkf8OFklXydQ/m6o56mGULHYIbLs=; b=Mtq0NPKwMy9OFhcEHr9sepQH4IMzZesmce8/fd/EJvJDTZmMplThk8rFnDL616Miv8 C9hsORShZT1X3LkOJwUx5ex++jkyyBCYf+EGgyuRD9hkcejOK+hrjK9l6Uk8wRKyyOFO mtbPq0EpewJFspQ0KBYJtKraUlP7LWR7jDIxMtBrm0UvvKy2J8svha+u09nmVMkejCSe Xu5qAm6zzd9IDIIA3B8crAlsxW/fkNip2qwkCLqRoqaq+99iQJhl4rUz5VnXkqGkditP 216p8qpHtAiSVayPhgyb/jmsgQU4nUBkF8BGWfGUVGNqUbdkvaQb2d1/fFp+VSz3tf7W TSBA== X-Gm-Message-State: AKwxytdQyzTZ7BlR32saGflCVsGr4TQsBIk8Vf4KdbodfUx3DaLa/JPW QAnXfc+4G81o/3UL2RYN6ltwhWqLGmQ= X-Google-Smtp-Source: AH8x224OPYOmFQbNs0RYuNQ2Y/dOGRx4BxLHzmee9HWktb5rpHVzIxWS9sTaiAMJ2rq+HuTLjHGPXQ== X-Received: by 10.28.105.214 with SMTP id z83mr19324300wmh.77.1517239982570; Mon, 29 Jan 2018 07:33:02 -0800 (PST) Received: from ?IPv6:2001:8a0:f915:7500:56ee:75ff:fe8d:232b? ([2001:8a0:f915:7500:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id 63sm14949685wms.46.2018.01.29.07.33.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jan 2018 07:33:01 -0800 (PST) Subject: Re: [RFC] regresssion(internal-error) printing subprogram argument To: Joel Brobecker References: <20171215094755.dwocipbcwvtdm6f6@adacore.com> <00320239-44c8-b9c3-013b-b27c771e3401@redhat.com> <07a154ef-b6f5-ad86-1410-a73620de4b5b@redhat.com> <20180103043345.n6blge377ybsdx6q@adacore.com> <8df5cf8b-6e4e-e310-fcbd-2615334fe5b9@redhat.com> <832dbb30-7c2b-40ed-c03c-654bd1e2ea32@redhat.com> <20180117091332.z7bqu4aljudq33sw@adacore.com> <20180126035055.vbjtowj6q5ftbwiz@adacore.com> <21bfbb6a-bb10-812b-c34a-d367321e8d5e@redhat.com> <20180129103841.kdkomcjbuwiat5b4@adacore.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <250976c6-6e7a-6a8e-b9f2-a57f5b92b965@redhat.com> Date: Mon, 29 Jan 2018 15:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180129103841.kdkomcjbuwiat5b4@adacore.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-01/txt/msg00594.txt.bz2 On 01/29/2018 10:38 AM, Joel Brobecker wrote: >> Indeed, looks like I don't have that. I have "interfacesS". >> I've attached the whole file. > > That explains it :). > >> So it may be that we still need to add another special case >> for Ada somewhere. Would old GDB from before the C++ >> wildmatching pass this test for you? > > I went binary searching for the source of the regression and > when I found that it was "caused" by the change requiring variables > without debugging information to be cast before they can be printed, > I gently head-slapped myself, adjusted the testcase to use something > other than an integer variable, and voila - even GDB 7.10 suffers > from the problem. We just didn't see it for integer variables simply > because we were lucky! > > I ran out of time again today, but at least the WIP patch got > augmented with a testcase that currently fails before the patch > is applied. > > I think the patch itself is probably correct, although I'd like > to do some archeology to understand the comment attached to > that location. I'm pretty confused by it, when we could simply > say that symbols from languages that do not follow the C++ mangling > should not be demangled by gdb_demangle -- at least for as long > as gdb_demangle is equivalent to cplusplus_demangle in practice... Yeah, the commentary around that code isn't exactly clear. Why doesn't that code use language->la_demangle instead, for example. The other day I noticed that gdb_demangle -> bfd_demangle -> cplus_demangle does have support for demangling other languages. For Ada, see the GNAT_DEMANGLING handling in libiberty.c:cplus-dem.c:cplus_demangle, which takes you to: /* Demangle ada names. The encoding is documented in gcc/ada/exp_dbug.ads. */ char * ada_demangle (const char *mangled, int option ATTRIBUTE_UNUSED) { When I saw that, I wondered why is it that GDB has a separate implementation of Ada decoding in gdb/ada-lang.c. The only plausible explanation I came up with is that gdb's version decodes into a buffer that is shared between invocations while libiberty's version always heap-allocates the result. Maybe it was an efficiency thing? Do you know? I ran into that around this discussion where I was wondering whether we could speed up demangling by letting bfd_demangle / cplus_demangle try all languages and return back which one worked: ~~~ An idea I had would be to try to combine most the language_sniff_from_mangled_name implementations in one call, by deferring to cplus_demangle which seems like could take care of gnu v3, rust, java, gnat, dlang and old C++ mangling schemes all at once. This would avoid the overhead of gdb_demangle and bfd_demangle for each language-specific demangling call, at least. Not sure. ~~~ Because ada_decode comes up high in profiles today... > > And just as a reminder for myself, I said in my other email > last week that I wanted also to review all the calls to gdb_demangle. Thanks, Pedro Alves