This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]