But then why does it work on Mac? MAC can be a different code path. There is quite a bit of code in that function that run for m_using_apple_tables.
Regards, Abid From: Zachary Turner [mailto:ztur...@google.com] Sent: 13 January 2015 17:58 To: Abid, Hafiz; lldb-dev@cs.uiuc.edu; Jim Ingham Subject: Re: [lldb-dev] Problem with ClangExpressionDeclMap But then why does it work on Mac? And why is this workaround needed at all, when you can just have it check the basename in the first place (e.g. in FindExternalVisibleDecls)? I guess a higher level, more general question - Why is name lookup so complicated? Clang already knows everything, why does LLDB need to modify the default behavior of Clang's name lookup? I know LLDB can insert its own decls into the AST, but it seems like we can just get avoid returning those to the user, and still use clang for everything else. On Tue Jan 13 2015 at 2:54:15 AM Abid, Hafiz <hafiz_a...@mentor.com<mailto:hafiz_a...@mentor.com>> wrote: In SymbolFileDWARF::FindFunctions (), there is code that runs only for Linux and BSD. That finds the function in global namespace. Regards, Abid From: lldb-dev-boun...@cs.uiuc.edu<mailto:lldb-dev-boun...@cs.uiuc.edu> [mailto:lldb-dev-boun...@cs.uiuc.edu<mailto:lldb-dev-boun...@cs.uiuc.edu>] On Behalf Of Zachary Turner Sent: 12 January 2015 19:51 To: lldb-dev@cs.uiuc.edu<mailto:lldb-dev@cs.uiuc.edu>; Jim Ingham Subject: [lldb-dev] Problem with ClangExpressionDeclMap Was looking into this bug<http://llvm.org/bugs/show_bug.cgi?id=22177> on Windows, and I traced it down to an issue in ClangExpressionDeclMap. ClangExpressionDeclMap::FindExternalVisibleDecls has a piece of code that looks like this: if (namespace_decl && module_sp) { const bool include_symbols = false; module_sp->FindFunctions(name, &namespace_decl, eFunctionNameTypeBase, include_symbols, include_inlines, append, sc_list); } else if (target && !namespace_decl) { const bool include_symbols = true; // TODO Fix FindFunctions so that it doesn't return // instance methods for eFunctionNameTypeBase. target->GetImages().FindFunctions(name, eFunctionNameTypeFull, include_symbols, include_inlines, append, sc_list); } So it's only searching for the base name if the function is in a namespace, and if it's at global scope it's searching for the full name. I'm not sure why this works on other platforms, but on Windows it doesn't work because if I have this code: int foo(int x) { } then the full name of this function is ?foo@@YAHH@Z If I change eFunctionNameTypeFull to eFunctionNameTypeBase then everything works, and "p foo" finds the function. So I've got a couple of questions: 1) Why all this complicated logic? I would expect that if I type "p foo" then it would just print everything whose base name is foo and is visible from within the current scope? Am I underthinking this? There's special cases for namespaces, global scope, instance methods, variables, functions, and it looks for things in certain orders, etc. Is there any reason why it can't just find everything with a basename of foo visible within the current stack frame? 2) I'm not sure what this comment means: // TODO Fix FindFunctions so that it doesn't return // instance methods for eFunctionNameTypeBase. I changed it to eFunctionNameTypeBase and it fixes the original bug on Windows. I inserted a class with an instance method named foo() and also a global method named foo(), and running "p foo" doesn't find the instance method, only the global method. Is it possible this was somehow fixed, and it was forgotten to change this back to eFunctionNameTypeBase? 3) Why does this work on other platforms? full names are mangled on other platforms too, so I don't know how "p foo" doesn't run into this same issue on other platforms. Any ideas? Currently the best fix I have for this bug on Windows is to change eFunctionNameTypeFull to eFunctionNameTypeBase. but I want to get some thoughts on that worrisome comment before I go forward with that patch.
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
