<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 3, 2018, at 7:38 AM, Pavel Labath via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hello all,<br class=""><br class="">/This may or may not be related to the "Issue with expression parser<br class="">finding the correct types" thread from last week./<br class=""><br class="">As you probably know, I am working on adding DWARF v5 accelerator tables to<br class="">lldb. To make that happen, I've been trying to understand how the two<br class="">existing indexing methods (apple tables and manually built indexes) work.<br class=""><br class="">While doing that, I was puzzled at the behavior of the FindFunctions method<br class="">for the case of name_type_mask = eFunctionNameTypeFull. The function seems<br class="">to do very different things depending on the index used (and both of them<br class="">seems to be broken in different ways).<br class=""><br class="">- for the apple case (SymbolFileDWARF.cpp:2496), the function will take the<br class="">name given, and look it up in the apple_names table (which contains base<br class="">names, mangled names, but *not* fully qualified demangled names). Then it<br class="">will simply return this list as a result (I am assuming we pass an empty<br class="">parent_decl_ctx, so no filtering done there). This seems weird, because<br class="">then a search for a name like "foo" will return any function whose base<br class="">name is "foo", including ones deeply nested inside other namespaces,<br class="">classes or other functions.<br class=""></div></div></blockquote><div><br class=""></div>DWARF currently only has mandatory function names that are the base function names with no decoration or qualification, and may or may not have the mangled names. I didn't wan't to require every mangled name to be demangled and placed in a collection of fully qualified demangled names as no one really searches using those names because if you get one space wrong, or mess anything up the lookups don't work. So the idea was:</div><div>1 - allow mangled name lookups for the compiler since JIT will lookup via the mangled names.</div><div>2 - allow lookup on basename and filter the results as needed</div><div><br class=""></div><div>So the current Apple approach is the way it is intended to work. That isn't to say that this is what the right thing to do going forward is. More on that below.</div><div><br class=""></div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""><br class="">- for the manual case (SymbolFileDWARF.cpp:2626), the function will look<br class="">into a special "full name" index, which contains mangled and<br class="">fully-qualified (with parameters and all) demangled names of all functions.<br class="">This would seem reasonable if it was not followed by a hac^H^H^Hworkaround,<br class="">which will, in case the previous search finds no match, look in the<br class="">*basename* index, and then accept any function whose demangled name begins<br class="">with the string "(anonymous namespace)" (which means it will include also<br class="">functions with mismatched arguments types or namespace qualifiers).<br class=""></div></div></blockquote><div><br class=""></div>So I would have the ::Index method skip creating the fully qualified names and populating an index based off of that because:</div><div>1 - it is expensive to create the qualified names and no one looks them up that way.</div><div>2 - the qualified names would need to ensure that they exactly match what the demangler would do if a mangled name were actually there</div><div><br class=""></div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""><br class="">So, what should be the correct behavior here? Both of these seem so wrong<br class="">(and different) that I am surprised that we did not run into issues here<br class="">before. Is it possible there is some additional filtering happening at a<br class="">different level that I am not aware of?<br class=""></div></div></blockquote><div><br class=""></div>So I believe the best way to proceed is the way the apple tables do things. Expect that lookups will happen on base names and filtering will happen elsewhere. This keeps the support needed for indexing to an acceptable minimum for all debug info formats and will still allow people to look things up.</div><div><br class=""></div><div>The way lookups happen right now can also be a relative match. Lets say you have a:</div><div><br class=""></div><div>namespace a {</div><div>namespace b {</div><div> int foo();</div><div>}</div><div>}</div><div><br class=""></div><div>If someone types "b b::foo", this currently works because the place that does the matching knows to split the string into a search for functions that have "foo", then filter the results out that don't have a "b::foo" in the matching fully qualified name. If the user typed "a::b::foo ()" then matching on qualified name would fail due to the extra space. If the function was const and we searched for "a::b::foo()const" that would fail due to the missing space before const. So my reasoning was to avoid having to normalize names because they don't match exactly. Mangled names have a predefined format that is specified exactly. Any other qualified names are not normalized so they become unwieldy to use for matches IMHO.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">PS: I tried adding assert(!name.contains("::")) into this function to see<br class="">how often we are calling this function with a "FQN" which is not simply a<br class="">basename. (This is interesting because for the apple case, this function<br class="">would always return 0 results for such queries.) Only 5 tests failed, and<br class="">in all of these, the asserting calls were originating from<br class="">IRExecutionUnit.cpp, which was trying to link the jitted expression with<br class="">the running program. What this code is doing is it takes a mangled name,<br class="">and then tries searching for functions with several names derived from it<br class="">(demangled names, the "const" version of the mangled name, etc.). So it<br class="">seems, that in this case, the value returned by FindFunctions for the<br class="">non-demangled names doesn't really matter, since IRExecutionUnit will just<br class="">retry the search with the mangled name, which will return the same answer<br class="">in both cases.<br class=""></div></div></blockquote><div><br class=""></div>I agree that for the expression parser what you noticed with the assert is ok. The real issue is when people don't fully qualify names they type (such as with "b::foo" mentioned above), and that means function breakpoints by name are the other main searching factor here.</div><div><br class=""></div><div>A few interesting points in the evolution of this approach:</div><div><br class=""></div><div>We used to have a client that was setting a breakpoint on a symbol function name "foo". This worked fine until he made his source file C++ and tried to use the symbol only, without debug info, so now the symbol name was "foo()" because that is what it demangled to. His breakpoint no longer worked. So we made the symbol table parsing code demangle symbols and find the basename of the functions so the symbol tables can implement the same searching available in the DWARF.</div><div><br class=""></div><div>So the current reasoning is:</div><div>1 - allow basename searches only so things are easy on the SymbolFile subclasses</div><div>2 - allow fully mangled name searches</div><div>3 - don't do fully qualified indexes because these are fraught with syntax issues regarding spacing and equivalency issues ("foo ()" == "foo()" etc).</div><div><br class=""></div><div>Things that could be improved</div><div>1 - all queries for finding functions/types/globals should take a SymbolContext that specifies the context that the lookup should be originating from. </div><div>2 - Don't pass a "CompilerDeclContext *parent_decl_context" since this requires that the "TypeSystem *" inside the CompilerDeclContext matches that being used by the Module/ObjectFile/SymbolFile. Pass in a tokenized version that can represent all languages. So you would say "I am looking for 'foo" in AbstractDeclContext that is in the translation unit.</div><div><br class=""></div><div>AbstractDeclContext would be something like:</div><div><br class=""></div><div>struct AbstractDeclContext {</div><div> enum KindFlag {</div><div> WildCard = 1u << 0,</div><div> TranslationUnit = 1u << 1,</div><div> Namespace = 1u << 2,</div><div> Class = 1u << 3,</div><div> Struct = 1u << 4,</div><div> Function = 1u << 5,</div><div> Anything = ~WildCard, // anything except wildcard</div><div> };</div><div><div> struct Context {</div><div> uint32_t kind_mask;</div><div> ConstString name;</div><div> };</div><div> LanguageType m_language;</div><div> std::vector<Context> m_context;</div><div class="">};</div><div class=""><br class=""></div><div class="">Before making a search you would create an AbstractDeclContext:</div><div class=""><br class=""></div><div class="">For a type at the top level we would make:</div><div class=""><br class=""></div><div class="">AbstractDeclContext context(<span style="font-size: 11px; background-color: rgb(255, 255, 255);" class="">eLanguageTypeC, {</span></div><div class=""><span style="font-size: 11px; background-color: rgb(255, 255, 255);" class=""> {</span>AbstractDeclContext::TranslationUnit, ""}</div><div class="">});</div><div class=""><br class=""></div><div class="">We don't need to specify the translation unit name unless we explicitly need the result to come only from a specific source file, in which case we could specify the name:</div><div class=""><br class=""></div><div class=""><div class="">AbstractDeclContext context(<span style="font-size: 11px; background-color: rgb(255, 255, 255);" class="">eLanguageTypeC, {</span></div><div class=""><span style="font-size: 11px; background-color: rgb(255, 255, 255);" class=""> {</span>AbstractDeclContext::TranslationUnit, "/tmp/main.c"}</div><div class="">});</div></div><div class=""><br class=""></div><div class="">Searching for "basic_string" inside the "std::__1" namespaces we would search for "basic_string" with the context:</div><div class=""><br class=""></div><div class="">AbstractDeclContext context(<span style="font-size: 11px; background-color: rgb(255, 255, 255);" class="">eLanguageTypeC, {</span></div><div class=""><span style="font-size: 11px; background-color: rgb(255, 255, 255);" class=""> {</span>AbstractDeclContext::Namespace, "std"}, </div><div class=""><span style="font-size: 11px; background-color: rgb(255, 255, 255);" class=""> {</span>AbstractDeclContext::Namespace, "__1"}</div><div class="">});</div><div class=""><br class=""></div><div class="">For a user typed lookup like "a::b::foo" we would look for "foo" and specify:</div><div class=""><br class=""></div><div class="">AbstractDeclContext context(<span style="font-size: 11px; background-color: rgb(255, 255, 255);" class="">eLanguageTypeC, {</span></div><div class=""><span style="font-size: 11px; background-color: rgb(255, 255, 255);" class=""> {</span>AbstractDeclContext::WildCard, "a"}, </div><div class=""><span style="font-size: 11px; background-color: rgb(255, 255, 255);" class=""> {</span>AbstractDeclContext::Anything, "b"}});</div><div class=""><br class=""></div><div class="">because we don't know if "a" or "b" is a namespace or class/struct, function. For "a" we specify WildCard, because we don't care what the parent context of "a" is. It isn't required to be at the root level.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">3 - An alternative to #2 is to have all FindFunction, FindTypes and FindGlobalVariables functions take a lambda that gets called for any matching results as they are found. The lambda that handles the matches would have a boolean that would say when to stop searching for more matches if we found what we are looking for. Why? Currently we have a "uint32_t max_matches" on some of the ::Find functions. This is bad because if we do a general lookup for "foo", we might ask for 1 result, but if we don't properly specify the context, then we might get one and only one incorrect results back. Some searches like "reference_type" are typedefs that are found inside of every STL class. This could result in all debug info being parsed for all STL classes if we do a broad search.</div><div class=""><br class=""></div><div class="">So things we need to think about:</div><div class="">- do we make SymbolFile interfaces simpler and make the filtering logic at a high level, or do we increase the complexity of these searches so they return fewer results and have each SymbolFile::FindXXXX() function more complex.</div><div class="">- do we agnostify the CompilerDeclContext so it works on any type system, or require the find function that searches multiple modules have to create or lookup a valid CompilerDeclContext prior to calling into each SymbolFile::FindXXX() call?</div><div class=""><br class=""></div><div class="">Greg Clayton</div><div class=""><br class=""></div></div></body></html>