This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Make Module::LookupInfo::Prune language-agnostic
AbandonedPublic

Authored by bulbazord on Jun 22 2022, 11:28 AM.

Details

Summary

Module::LookupInfo::Prune tries to prune results from lookups that don't
match the user-provided lookup information. If we're trying to match a
name with type eFunctionNameTypeFull, we want to match what the user
provided exactly. Currently, we try to see if what the user provided is
matches exactly assuming that a C++ name was provided. However, this is
specific to the C++ debugging path. LLDB supports more languages than
C++, so it is important that this codepath be language-agnostic.

Diff Detail

Event Timeline

bulbazord created this revision.Jun 22 2022, 11:28 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 22 2022, 11:28 AM
bulbazord requested review of this revision.Jun 22 2022, 11:28 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 22 2022, 11:28 AM

How hot is this code? Parsing a demangled name isn't entirely cheap, and the fact that the objc++ class calls back into the c++ version means that the c++ name will be parsed twice.

Could we move this pruning elsewhere? These values come from the symbol file plugins anyway, and they can do a better job at determining which language does a particular name belong to.

(OK, they can an also come from the symtab, but there I guess we could infer something from the mangling scheme).

lldb/include/lldb/Target/Language.h
320

I think we're passing ConstStrings by value these days...

How hot is this code? Parsing a demangled name isn't entirely cheap, and the fact that the objc++ class calls back into the c++ version means that the c++ name will be parsed twice.

Not sure, I'll measure this. Also, at least on my machine, the list of language plugins includes at least 3 C++ language plugins, so it happens *at least* twice...

Could we move this pruning elsewhere? These values come from the symbol file plugins anyway, and they can do a better job at determining which language does a particular name belong to.
(OK, they can an also come from the symtab, but there I guess we could infer something from the mangling scheme).

We're specifically pruning the results from a name lookup, so I'm not sure where would be a better place to move it. That being said, based on your observation, we could try to do a better job of inferring the language a name belongs to by looking at the mangling scheme before we look at every single language plugin.

lldb/include/lldb/Target/Language.h
320

I see. Is there a reason we do that instead of passing by reference?

Could we move this pruning elsewhere? These values come from the symbol file plugins anyway, and they can do a better job at determining which language does a particular name belong to.
(OK, they can an also come from the symtab, but there I guess we could infer something from the mangling scheme).

We're specifically pruning the results from a name lookup, so I'm not sure where would be a better place to move it.

Well. I guess ideally I would pass whatever information is needed into the lookup functions themselves, so that there is no need for the additional filtering. I don't know why it's done this way but this setup seems inefficient, as we have to generate all these SymbolContext only for them to be (potentially) thrown away...

lldb/include/lldb/Target/Language.h
320

ConstString is just a fancy wrapper around a const char *, so adding a layer of indirection does not really save us anything (in fact, it's the opposite).

Could we move this pruning elsewhere? These values come from the symbol file plugins anyway, and they can do a better job at determining which language does a particular name belong to.
(OK, they can an also come from the symtab, but there I guess we could infer something from the mangling scheme).

We're specifically pruning the results from a name lookup, so I'm not sure where would be a better place to move it.

Well. I guess ideally I would pass whatever information is needed into the lookup functions themselves, so that there is no need for the additional filtering. I don't know why it's done this way but this setup seems inefficient, as we have to generate all these SymbolContext only for them to be (potentially) thrown away...

I see what you mean now. I'll look at this instead, maybe we can get rid of LookupInfo::Prune altogether. :)

lldb/include/lldb/Target/Language.h
320

Ah, this makes sense. I should have looked at ConstString more closely. Thank you! :)

bulbazord abandoned this revision.Jul 20 2022, 12:57 PM