This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] regresssion(internal-error) printing subprogram argument
> > 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><a9f>: Abbrev Number: 35 (DW_TAG_variable)
| <aa0> DW_AT_name : (indirect string, offset: 0x3fd): ada_main__u00045
| <aa4> DW_AT_decl_file : 5
| <aa5> DW_AT_decl_line : 128
| <aa6> DW_AT_linkage_name: (indirect string, offset: 0x198c): interfaces__cS
| <aaa> DW_AT_type : <0x79>
| <aae> DW_AT_external : 1
| <aae> 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?
--
Joel
>From d98976141c88b05f414bc8975ee2d77e3e655708 Mon Sep 17 00:00:00 2001
From: Joel Brobecker <brobecker@adacore.com>
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