[Lldb-commits] [lldb] Remove redundant symbol lookups in IRExecutionUnit::FindInSymbols (PR #102835)
Dmitrii Galimzianov via lldb-commits
lldb-commits at lists.llvm.org
Wed Aug 14 21:34:55 PDT 2024
DmT021 wrote:
Could you please explain to me why we use different rules in symbol lookups? Namely:
- [ClangExpressionDeclMap::GetSymbolAddress](https://github.com/llvm/llvm-project/pull/102835/files#diff-5d2da8306a4f4991885836925979f188658789adc8041c37811c243f2cdca24c) doesn't search in the ModuleList if a module is given even if the search provides no results.
- [SymbolContext::FindBestGlobalDataSymbol](https://github.com/llvm/llvm-project/pull/102835/files#diff-da1a374f5098c39acfebae4b87a261f143a842e613082c2296de7ee28df12a33) searches in the module first, then checks the results; if exactly one external or internal symbol is found returns it. Otherwise, if more than 1 is found it produces an error. But if nothing is found in the module it searches in the module list and repeats the checks.
So theoretically there could be multiple results in the module list that would trigger an error, but we don't check for them.
Also, it seems an external symbol takes precedence over an internal symbol. If we found an internal symbol in the module, we still could find an external symbol in the module list, but we don't search for it. Is this correct? Does an internal symbol of the module actually take precedence over an external symbol from the module list?
- [IRExecutionUnit::FindInSymbols](https://github.com/llvm/llvm-project/pull/102835/files#diff-717a850c4315286c025e2739ebe9dacbf27e626b7679c72479b05c996d721112) looks similar to the previous one, but actually very different. It returns early if and only if the found symbol is external(see LoadAddressResolver::Resolve), otherwise it does a full search in the module list. And only then if an external symbol isn't found - returns the first internal symbol(if any).
It's hard to generalize the optimization since all the callers post-process the results differently.
https://github.com/llvm/llvm-project/pull/102835
More information about the lldb-commits
mailing list