[lldb-dev] What should SymbolFile::FindFunctions(..., eFunctionNameTypeFull, ...) do ?

[Pavel Labath via lldb-dev]

Hello all,

/This may or may not be related to the "Issue with expression parser
finding the correct types" thread from last week./

As you probably know, I am working on adding DWARF v5 accelerator tables to
lldb. To make that happen, I've been trying to understand how the two
existing indexing methods (apple tables and manually built indexes) work.

While doing that, I was puzzled at the behavior of the FindFunctions method
for the case of name_type_mask = eFunctionNameTypeFull. The function seems
to do very different things depending on the index used (and both of them
seems to be broken in different ways).

- for the apple case (SymbolFileDWARF.cpp:2496), the function will take the
name given, and look it up in the apple_names table (which contains base
names, mangled names, but *not* fully qualified demangled names). Then it
will simply return this list as a result (I am assuming we pass an empty
parent_decl_ctx, so no filtering done there). This seems weird, because
then a search for a name like "foo" will return any function whose base
name is "foo", including ones deeply nested inside other namespaces,
classes or other functions.

- for the manual case (SymbolFileDWARF.cpp:2626), the function will look
into a special "full name" index, which contains mangled and
fully-qualified (with parameters and all) demangled names of all functions.
This would seem reasonable if it was not followed by a hac^H^H^Hworkaround,
which will, in case the previous search finds no match, look in the
*basename* index, and then accept any function whose demangled name begins
with the string "(anonymous namespace)" (which means it will include also
functions with mismatched arguments types or namespace qualifiers).

So, what should be the correct behavior here? Both of these seem so wrong
(and different) that I am surprised that we did not run into issues here
before. Is it possible there is some additional filtering happening at a
different level that I am not aware of?

PS: I tried adding assert(!name.contains("::")) into this function to see
how often we are calling this function with a "FQN" which is not simply a
basename. (This is interesting because for the apple case, this function
would always return 0 results for such queries.) Only 5 tests failed, and
in all of these, the asserting calls were originating from
IRExecutionUnit.cpp, which was trying to link the jitted expression with
the running program. What this code is doing is it takes a mangled name,
and then tries searching for functions with several names derived from it
(demangled names, the "const" version of the mangled name, etc.). So it
seems, that in this case, the value returned by FindFunctions for the
non-demangled names doesn't really matter, since IRExecutionUnit will just
retry the search with the mangled name, which will return the same answer
in both cases.

regards,
pavel