[Lldb-commits] [lldb] Remove redundant symbol lookups in IRExecutionUnit::FindInSymbols (PR #102835)

Greg Clayton via lldb-commits lldb-commits at lists.llvm.org
Wed Aug 28 10:29:48 PDT 2024


clayborg wrote:

> I think Greg is saying that if we don't find a local symbol, and don't find the symbol in the global symbols of the current module, then we should search all the other modules, but in that case preferring external symbols to internal since those are the ones that are potentially visible from the CU we started from. Jim
> […](#)
> On Aug 28, 2024, at 1:04 AM, Michael Buch ***@***.***> 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 <[#102835 (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." — Reply to this email directly, view it on GitHub <[#102835 (comment)](https://github.com/llvm/llvm-project/pull/102835#issuecomment-2314614570)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUPVW6JZ2OQ6EGACD72SYDZTWACNAVCNFSM6AAAAABMLEK6UGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJUGYYTINJXGA>. You are receiving this because you are on a team that was mentioned.

yes. If we can do it, find something in the local compile unit first, if there are two symbols in the CU, then the public one, else the private. Fall back to the current module, first public, then private. And repeat with all modules, and if we find only 1 public symbol, use that, else fall back to a single private symbol. If there are multiple symbols on all modules, then we emit an error.

https://github.com/llvm/llvm-project/pull/102835


More information about the lldb-commits mailing list