From patchwork Fri Jan 26 04:50:47 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joel Brobecker X-Patchwork-Id: 25547 Received: (qmail 35176 invoked by alias); 26 Jan 2018 04:50:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 34581 invoked by uid 89); 26 Jan 2018 04:50:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-23.7 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_STOCKGEN, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 26 Jan 2018 04:50:53 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 2203D116D8A; Thu, 25 Jan 2018 23:50:52 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id P1tfTUdm0+8L; Thu, 25 Jan 2018 23:50:52 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id A7C5E116D2A; Thu, 25 Jan 2018 23:50:51 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 5538383307; Fri, 26 Jan 2018 08:50:47 +0400 (+04) Date: Fri, 26 Jan 2018 08:50:47 +0400 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [RFC] regresssion(internal-error) printing subprogram argument Message-ID: <20180126045047.qy3q5efr3trlpfkv@adacore.com> References: <20171213103655.msbaxfrykc36f4a7@adacore.com> <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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180117091332.z7bqu4aljudq33sw@adacore.com> User-Agent: NeoMutt/20170113 (1.7.2) > > I'm curious to know if after all the fixing you still see > > the KFAIL on your end. I get: > > > > KPASS: gdb.ada/maint_with_ada.exp: maintenance check-psymtabs (PRMS gdb/22670) > > Strange, I still get the error: > > (gdb) maintenance check-psymtabs > Global symbol `interfaces__cS' only found in /[...]/gdb.ada/maint_with_ada/b~var_arr_typedef.adb psymtab > (gdb) KFAIL: gdb.ada/maint_with_ada.exp: maintenance check-psymtabs (PRMS: gdb/22670) For the sake of this investigation, I used a simpler program: | $ cat a.adb | procedure A is | begin | null; | end A; The symbol in question is declared in b~a.ads as follow: | u00045 : constant Version_32 := 16#f60287af#; | pragma Export (C, u00045, "interfaces__cS"); The debugging information for this variable looks like this: | <1>: Abbrev Number: 35 (DW_TAG_variable) | DW_AT_name : (indirect string, offset: 0x3fd): ada_main__u00045 | DW_AT_decl_file : 5 | DW_AT_decl_line : 128 | DW_AT_linkage_name: (indirect string, offset: 0x198c): interfaces__cS | DW_AT_type : <0x79> | DW_AT_external : 1 | DW_AT_location : 9 byte block: 3 80 e5 41 0 0 0 0 0 (DW_OP_addr: 41e580) The important bit is that it has a DW_AT_linkage_name attribute. When we look at dwarf2read.c::new_symbol, we can see: | /* Cache this symbol's name and the name's demangled form (if any). */ | SYMBOL_SET_LANGUAGE (sym, cu->language, &objfile->objfile_obstack); | linkagename = dwarf2_physname (name, die, cu); | SYMBOL_SET_NAMES (sym, linkagename, strlen (linkagename), 0, objfile); In our case, LINKAGENAMES is "interfaces(char, signed)"; as you intuitively guessed, C++ demangling was applied on the symbol. Following that thread and looking at dwarf2_physname, we see that it basically calls gdb_demangle, and that works, then returns its value as the physname. Continuing on, gdb_demangle is just a wrapper for bfd_demangle, and neither take any language information as a parameter. And looking at bfd_demangle I found that it is just a wrapper around cplus_demangle. Since Ada does not follow the same encoding technique, this should not be done for Ada symbols. Attached is a prototype patch which hacks that idea into the current code. It was tested on x86_64-linux, and both fixes the KFAIL and shows no regression. I don't understand the command regarding go; it was just a convenient location for adding the condition. The part that worries me is that we have several other other locations where gdb_demangle is being called. Half of them are from language- specific areas, so probably not an issue for Ada. But I think I will review the other ones... To be continued. Thoughts? From d98976141c88b05f414bc8975ee2d77e3e655708 Mon Sep 17 00:00:00 2001 From: Joel Brobecker Date: Thu, 25 Jan 2018 23:23:54 -0500 Subject: [PATCH] WIP: dwarf2read.c::dwarf2_physname: do not call gdb_demangle with Ada symbols --- gdb/dwarf2read.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c index 96026a8..dfed170 100644 --- a/gdb/dwarf2read.c +++ b/gdb/dwarf2read.c @@ -11127,7 +11127,7 @@ dwarf2_physname (const char *name, struct die_info *die, struct dwarf2_cu *cu) variant `long name(params)' does not have the proper inferior type. */ - if (cu->language == language_go) + if (cu->language == language_go || cu->language == language_ada) { /* This is a lie, but we already lie to the caller new_symbol. new_symbol assumes we return the mangled name. -- 2.1.4