> > 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