[Lldb-commits] [PATCH] D129682: [lldb] Filter DIEs based on qualified name when possible

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.


================
Comment at: lldb/source/Core/Module.cpp:740
+  bool user_provided_name_is_mangled =
+      Mangled::GetManglingScheme(m_name.GetStringRef()) !=
+      Mangled::eManglingSchemeNone;
----------------
bulbazord wrote:
> labath wrote:
> > labath wrote:
> > > I think this is overly aggressive. `_Z3foov` could be a method name in some particularly sadistic class. I think you can do this optimization only in one direction: if the names match, then return true without consulting the language plugin. At that point, I don't think you even need to check whether the names are mangled.
> > Actually, this could go wrong even for names like `_Zonk`, since `GetManglingScheme` does not check that the string is an actually valid mangled name -- just that it looks like one from very far away.
> Then in that case, perhaps this method should always take a demangled name? If it can take mangled names, it seems like a giant pain and potentially pretty expensive to figure out if it's mangled or not, especially given that in the sadistic case a name could look mangled but actually be the demangled name. Am I following your thought correctly?
Not exactly. The way that lookup works in lldb (or at least, how I understand it) is that the user gives you a "name" and then you go on to match that name against various "things". Those things include stuff like the mangled name, full demangled name, basename, etc. The set of things to match can be constrained by through extra arguments (e.g. `br set --fullname` vs. `br set --basename`), but I don't think we have a way to say "match against mangled names _only_" -- things like `br set --fullname _Z3foov` will both match the function whose mangled name is that string (i.e. `foo()`) and the function which has that as its demangled name (`_Z3foov()` aka. `_Z7_Z3foovv`).

So I'd say this should just match both names without trying to be particularly efficient about it (obviously it can skip the demangle step if the mangled name already matches).

I'd also say it's possible I don't understand the context in which this function is invoked...


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D129682/new/

https://reviews.llvm.org/D129682