Re: Fix gdb.ada/bp_c_mixed_case.exp (PR gdb/22670) (Re: [PATCH 3/3] Add new gdb.ada/bp_c_mixed_case testcase for PR gdb/22670)

[Joel Brobecker <brobecker@adacore.com>]

> > I am wondering why minimal symbols are involved in this case,
> > considering that the C file was build with debugging information.
> > Shouldn't we be getting the function's address from the partial/full
> > symtabs instead?
> 
> AFAIK, GDB always worked this way for linespecs, even before my C++
> wildmatching patches -- we collect symbols from both debug info and
> minsyms, and coalesce them by address to avoid duplicates
> (linespec.c:add_matching_symbols_to_info).  

That's true.

What surprises me is that, before your patch, we were finding
no symbol at all. So we were failing the lookup both with minimal
symbols, and within the partial/full symtab.

Your patch, IIUC, handles the lookup at the minimal symbol level,
which is indeed a good thing. But shouldn't we also be finding
that same symbol through the partial/full symtab search? I have
a feeling that your minimal symbol patch might be hiding a bug
in the search for the symbol, at least from the linespec module.

I did a bit of debugging this morning, first with the following
snapshot, which is shortly before the wild-matching patch series:

    commit b346cb961f729e2955391513a5b05eaf02b308ea
    Author: GDB Administrator <gdbadmin@sourceware.org>
    Date:   Wed Nov 8 00:00:20 2017 +0000

The function iterate_over_all_matching_symtabs finds the function
in the bar.c's partial symtab because the matching function is...

           [&] (const char *symbol_name)
           {
             return symbol_name_cmp (symbol_name, name) == 0;
           },

... where name, in this case is "MixedCaseFunc" -- The "<>" has been
stripped. They got stripped by linespec.c::find_linespec_symbols
when it took that name and converted it to a lookup name via:

  if (state->language->la_language == language_ada)
    {
      /* In Ada, the symbol lookups are performed using the encoded
         name rather than the demangled name.  */
      ada_lookup_storage = ada_name_for_lookup (name);
      lookup_name = ada_lookup_storage.c_str ();
    }
  else
    {
      lookup_name = demangle_for_lookup (name,
                                         state->language->la_language,
                                         demangle_storage);
    }

In the newer version, find_linespec_symbols gets passed the lookup_name
directly, and that lookup_name is now "<MixedCaseFunc>". Those extra
"<...>" are what eventually gets in the way when we compare this
lookup_name against the partial's symbols name (in
default_symbol_name_matcher, which does an strncmp_iw_with_mode
comparison, IIUC).

The call to find_linespec_symbols comes from linespace_parse_basic,
which has:

  /* Try looking it up as a function/method.  */
  find_linespec_symbols (PARSER_STATE (parser),
                         PARSER_RESULT (parser)->file_symtabs, name,
                         PARSER_EXPLICIT (parser)->func_name_match_type,
                         &symbols, &minimal_symbols);

I really hate to be stopping the investigation at this point, as
I feel I am onto something, but I am running out of time for today.

The part where I am not sure yet is whether we should be transforming
"name" into a "lookup_name" before calling find_linespec_symbols, or
whether we should be handling the angle brackets during the symbol
comparison... Or something else entirely! This is still all fairly
new to me...

Note that I was thinkg we would need to be stripping the executable
for us to demonstrate an error, but in fact, this is what happens
if I use "print" instead of "break":

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

With the snapshot prior to the patch series, GDB knows that
MixedCaseFunc is a function without parameters, and the expression
above means calling it. As I was debugging without having started
the inferior, I got the following (expected) error:

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

in the bp_c_mixed_case.exp, we should see GDB telling us that
we stopped on our MixedCaseFunc breakpoint while evaluating
a function call...

Does this make some kind of sense to you? I can get back to this
for more digging again tomorrow.

Thanks!
-- 
Joel