Ada: make verbatim matcher override other language matchers (PR gdb/22670)

A previous patch fixed verbatim matching in the lookup at the minimal
symbol level, but we should also be finding that same symbol through
the partial/full symtab search.

For example, this is what happens if we use "print" instead of
"break":

    (gdb) p <MixedCaseFunc>
    $1 = {<text variable, no debug info>} 0x4024dc <MixedCaseFunc>

Before the C++ wildmatching series, GDB knows that MixedCaseFunc is a
function without parameters, and the expression above means calling
it.  If you try it before having started the inferior, you'd get the
following (expected) error:

    (gdb) print  <MixedCaseFunc>
    You can't do that without a process to debug.

The main idea behind making the name matcher be determined by the
symbol's language is so that C++ (etc.) wildmatching in linespecs
works even if the current language is not C++, as e.g., when you step
through C or assembly code.

Ada's verbatim matching syntax however ("<...>") isn't quite the same.
It is more a property of the current language than of a particular
symbol's language.  We want to support this syntax when debugging an
Ada program, but it's reason of existence is to find non-Ada symbols.
This suggests going back to enabling it depending on current language
instead of language of the symbol being matched.

I'm not entirely happy with the "current_language" reference (though I
think that it's harmless).  I think we could try storing the current
language in the lookup_name_info object, and then convert a bunch of
functions more to pass around lookup_name_info objects instead of
"const char *" names.  I.e., build the lookup_name_info higher up.
I'm not sure about that, I'll have to think more about it.  Maybe
something different will be better.  Meanwhile, this gets us going.

I've extended the testcase to also exercise a no-debug-info function,
for extra coverage of the minsyms-only paths.

gdb/ChangeLog:
2018-01-10  Pedro Alves  <palves@redhat.com>

	PR gdb/22670
	* dwarf2read.c
	(gdb_index_symbol_name_matcher::gdb_index_symbol_name_matcher):
	Adjust to use language_get_symbol_name_matcher instead of
	language_defn::la_get_symbol_name_matcher.
	* language.c (language_get_symbol_name_matcher): If in Ada mode
	and the lookup name is a verbatim match, return Ada's matcher.
	* language.h (language_get_symbol_name_matcher): Adjust comment.
	(ada_lookup_name_info::verbatim_p):: New method.

gdb/testsuite/ChangeLog:
2018-01-10  Pedro Alves  <palves@redhat.com>

	PR gdb/22670
	* gdb.ada/bp_c_mixed_case.exp: Add intro comment.  Test printing C
	functions too.  Test setting breakpoints and printing C functions
	with no debug info too.
	* gdb.ada/bp_c_mixed_case/qux.c: New file.

1 files changed, 15 insertions, 17 deletions

diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index a3028e5c52..8bdac576bd 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -4529,23 +4529,21 @@ gdb_index_symbol_name_matcher::gdb_index_symbol_name_matcher
   for (int i = 0; i < nr_languages; i++)
     {
       const language_defn *lang = language_def ((enum language) i);
-      if (lang->la_get_symbol_name_matcher != NULL)
-	{
-	  symbol_name_matcher_ftype *name_matcher
-	    = lang->la_get_symbol_name_matcher (m_lookup_name);
-
-	  /* Don't insert the same comparison routine more than once.
-	     Note that we do this linear walk instead of a cheaper
-	     sorted insert, or use a std::set or something like that,
-	     because relative order of function addresses is not
-	     stable.  This is not a problem in practice because the
-	     number of supported languages is low, and the cost here
-	     is tiny compared to the number of searches we'll do
-	     afterwards using this object.  */
-	  if (std::find (matchers.begin (), matchers.end (), name_matcher)
-	      == matchers.end ())
-	    matchers.push_back (name_matcher);
-	}
+      symbol_name_matcher_ftype *name_matcher
+	= language_get_symbol_name_matcher (lang, m_lookup_name);
+
+      /* Don't insert the same comparison routine more than once.
+	 Note that we do this linear walk instead of a seemingly
+	 cheaper sorted insert, or use a std::set or something like
+	 that, because relative order of function addresses is not
+	 stable.  This is not a problem in practice because the number
+	 of supported languages is low, and the cost here is tiny
+	 compared to the number of searches we'll do afterwards using
+	 this object.  */
+      if (name_matcher != default_symbol_name_matcher
+	  && (std::find (matchers.begin (), matchers.end (), name_matcher)
+	      == matchers.end ()))
+	matchers.push_back (name_matcher);
     }
 }