[Lldb-commits] [PATCH] D12809: Better scheme to lookup alternate mangled name when looking up function address.

Siva Chandra via lldb-commits lldb-commits at lists.llvm.org
Mon Sep 14 13:44:19 PDT 2015


sivachandra added inline comments.

================
Comment at: source/Expression/ClangExpressionDeclMap.cpp:661
@@ -603,4 +660,3 @@
                 {
-                    FindCodeSymbolInContext(
-                        demangled, m_parser_vars->m_sym_ctx, eFunctionNameTypeFull, sc_list);
-                    sc_list_size = sc_list.GetSize();
+                    ConstString best_alternate_mangled_name = FindBestAlternateMangledName(demangled, lang_type, sc);
+                    if (best_alternate_mangled_name)
----------------
spyffe wrote:
> This should definitely only be done if we can't find the name the original way.  I'm always happy to pay extra runtime to fix an expression that would otherwise not work – but expressions that would work (the >90% case) shouldn't be paying for this.
The "original" way is still attempted first at line 643 above. Lines 669 to 674 below take care of another problem: http://reviews.llvm.org/D12613. Since that problem is much more a rare case than that solved in this change, I chose to keep this "try" before that "try".

================
Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h:200
@@ -198,1 +199,3 @@
 
+    void
+    GetMangledNamesForFunction (const std::string &scope_qualified_name,
----------------
spyffe wrote:
> Why is this attached to the DWARF?  I would want to attach this to the ClangExpressionDeclMap because we identify these alternate names during function name lookup, and we just need to remember them when resolving the references in IR.  After that, they are no longer needed.
My thinking was, DWARF is the only thing which knows about the correct mangled name, so keep it close to the code dealing with DWARF. Your suggestion also makes sense, but might (I have not yet thought enough about it) require us to expose DIE info into ClangExpressionDeclMap. I will think more about this approach and get back to you.


http://reviews.llvm.org/D12809





More information about the lldb-commits mailing list