jimingham wrote:
> On Aug 28, 2024, at 3:43 PM, Michael Buch ***@***.***> wrote: > > > 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. > > I guess here lies my hangup. What is the distinction between local and > private lldb_private::Symbols here? And why prefer the global over the > private (if we're stopped in a context where the private symbol is visible > according to language rules)? > The first goal of the expression parser is to emulate the symbol lookups that the compiler would have done were you compiling code in this context. So if you can resolve a symbol name to one that the compiler could see, then you should stop there - you have the right answer. So for instance if there is a local with that name, we should look no further. If there is a static in the CU you are stopped in with that name, we should use that and stop looking. The issue comes when we can't find a symbol that would be visible according to the language rules. Do we just give up? That isn't very helpful because sometimes you really do want to access symbols beyond what those that can be seen in that CU. So we made up some heuristics that we can use to find the best candidate. If we search the entire symbol world and there's only one instance of a matching symbol to be most helpful we should use that one regardless of visibility. So we could make our heuristic be "search the rest of the world for the symbol, and if we find only one instance, use that, otherwise give up". But that's also not very helpful, so we added some more rules. For instance, an exported symbol in some other library might have been visible in our CU's context (we don't know because we can't tell how the binary was linked, but because it's an exported symbol, it could have been). OTOH, a non-exported symbol in some other library could never have been visible to it. So it makes sense to resolve duplicate symbols in favor of the exported symbol. The resolution of your hangup is that we're talking here about the "failed to find an obviously correct symbol match" fallbacks. If there's an obviously correct one according to the language rules, we definitely should not be using these fallbacks. Jim > — > Reply to this email directly, view it on GitHub > <https://github.com/llvm/llvm-project/pull/102835#issuecomment-2316364777>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ADUPVW4XZ7R6TDUFHIDACITZTZHANAVCNFSM6AAAAABMLEK6UGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJWGM3DINZXG4>. > You are receiving this because you are on a team that was mentioned. > 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
