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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to