[RFC] regresssion(internal-error) printing subprogram argument

  Here is the latest update for this thread. I'm pretty much ready
to work on an official patch, but I'd like some guidance.

A quick summary:

      We noticed that, with Ada programs, "maintainance check-psymtabs"
      reports consistency check error for symbols such as "interfaces__cS".
      This happens for symbols whose linkage name resembles a C++ mangled
      name. In that situation, dwarf2physname finds the linkage name,
      and then processes it through gdb_demangle, regardless of the
      unit's language.  As a result, we end up storing the symbol
      linkage name using the demangled name, which makes no sense
      for Ada, and thus triggers the consistency check failure.

The fix for the various testcases (one in C, one in the existing
Ada testcase) is to patch dwarf2_physname to avoid calling gdb_demangle
for languages where it doesn't make sense. The big question is:
which languages should we exclude? For now, I've decided to only
touch languages where I am sure: Ada, of course, but also
C, Asm, and "minimal".

There was the question of Go, but I'm not sure what go does in terms
of mangling. If you remember, symbols from Go units do not process
symbols' linkage name through gdb_demangle, but for reasons that are
unclear. Here is the comment:

      if (cu->language == language_go)
        {
          /* This is a lie, but we already lie to the caller new_symbol.
             new_symbol assumes we return the mangled name.
             This just undoes that lie until things are cleaned up.  */

I went looking for the origin of this comment, and unfortunately, it
was introduced as part of the large patch that introduced GO support
(circa Apr 2012). Not much information there.

To play it safe, I decided to fix dwarf2_physname independently
of go, so that go's comment doesn't bleed into this fix.

I also spent some time investigating all the calls to gdb_demangle.
The vast majority are obviously in a situation where we're dealing
with C++ types, or at least language-specific types where the language
is known. So the assumption is that we know what we're doing and
the call is OK.

As a result, there were only the 3 instances in dwarf2read.c.
One of them is the dwarf2_physname function, which is fixed here.
The other two are:

  (a) fixup_partial_die:

      | /* GCC might emit a nameless struct or union that has a linkage
      |    name.  See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47510.  */
      | if (part_die->name == NULL
      |     && (part_die->tag == DW_TAG_class_type
      |         || part_die->tag == DW_TAG_interface_type
      |         || part_die->tag == DW_TAG_structure_type
      |         || part_die->tag == DW_TAG_union_type)
      |     && part_die->linkage_name != NULL)

  (b) dwarf2_name:

      | case DW_TAG_class_type:
      | case DW_TAG_interface_type:
      | case DW_TAG_structure_type:
      | case DW_TAG_union_type:
      | [...]
      |   /* GCC might emit a nameless typedef that has a linkage name.  See
      |      http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47510.  */
      |   if (!attr || DW_STRING (attr) == NULL)

Theoretically, we might have an issue where we might be calling
gdb_demangle improperly for those types, and we could try to fix that.
However, the fix in those two situations is not clearly obvious.
And to top it all off, the equivalent situation might not exist
outside of certain versions of C++. So I would like to suggest
we leave those areas alone for now.

In terms of the fix, we have several alternatives. I discarded
the idea of hard-coding the list of languages we want to exclude
in dwarf2_physname as we might need that list elsewhere.

We have the option of a function (like in the attached patch),
probably to be moved to symtab.h/symtab.c. I chose a name that
spoke to me, but I'm completely familiar with the new lookup
system entirely yet, so better name suggestions are welcome.
For instance, instead of talking of symbol name storage format,
we could have something like...

    symbol_lookup_uses_demanged_name_p (enum language lang);

All in all, I think a better solution would be to put that information
directly in the language_defn itself, via a new "attribute".
Something like a...

    /* True if symbol search names should be stored in demangled
       format.  False otherwise.  */
    const bool symbol_stored_in_demangle_form_p;

Then, I'd set it to "true" for all languages, except the languages
we selected (Ada, C, Asm, minimal). I didn't implement that
just yet, as this requires a larger number of files being modified,
so I thought I'd seek opinions before going ahead.

My vote: a new language_defn attribute.  Thoughts?

gdb/ChangeLog:

        PR gdb/22670:
	* dwarf2read.c (symbols_stored_in_demangled_form_p): New function.
        (dwarf2_physname): Do not call gdb_demangle if
        symbols_stored_in_demangled_form_p returns false for
        the cu's language.

gdb/testsuite/ChangeLog:

        * gdb.ada/notcplusplus: New testcase.
        * gdb.ada/maint_with_ada.exp: Remove setup_kfail.
        * gdb.base/c-linkage-name.c: New file.
        * gdb.base/c-linkage-name.exp: New testcase.

Tested on x86_64-linux, no regression.

Thank you!

[RFC] regresssion(internal-error) printing subprogram argument

Commit Message

Patch