Michael137 wrote: > > > What happens if we stop preferring the external symbols over internal > > > ones in IRExecutionUnit::FindInSymbols? What tests break? > > > > > > It looks like there are no failing tests. > > We should always prefer symbols from the current module first, probably > external first, then fall back to internal. If we do a search of all modules, > we should prefer external symbols first and then internal, but only if they > are unique. Just think about how a symbol would be resolved inside of a > shared library vs how it would get accessed from outside of the shared > library. Debuggers can break the rules when we need to, but we should try to > stay true to how things would actually happen when possible first.
Just for my own understanding, could you elaborate on this? If we're doing a local module search and find an internal symbol (AFAIU, here an internal symbol means local to the CU, not a weak definition) why would we still prefer the external symbol? As you said [in your previous comment](https://github.com/llvm/llvm-project/pull/102835#issuecomment-2290670412): "If you have an expression like my_global, you really want to look at the compile unit your expression is being run from, and if that compile unit has a global or static variable named my_global, we should pick that one. If there isn't a match in the current compile unit, then we should search in the current module. If it has one, that is most likely the global the user wants." 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
