[Lldb-commits] [PATCH] D39307: Fix global data symbol resolution

[Alex Langford via Phabricator via lldb-commits]

xiaobai added a comment.

In https://reviews.llvm.org/D39307#907253, @jingham wrote:

> If I have a library that uses some singleton class that's not exported, and I'm debugging code in a client of my library, and the state of my library is looking odd based on what it is returning to the client, it seems not unnatural to want to call:
>
> (lldb) expr my_library_singleton->WFTDude()
>
> accessing some debugging function I've put in for that purpose.  This change would make that not work.


While not implausible, it seems as though making `my_library_singleton` visible from a scope that it is not intended to be visible from is causing the problem I am trying to fix. If your library is acting strange while interacting with your client, it seems like it's your library that you're really interested in debugging (or rather, your library interacting with the client), in which case you should probably enter the library's scope and then try to query its internals. While what you want to do is quite convenient, it possibly introduces more problems than it aims to alleviate.

However, I don't see a problem with adding a flag to expr to say "I want visibility from the scope of this module/library/whatever". In that case, we could create an expression in some dummy function within the context of the module we care about and use that to interact with clang. I'm not sure how feasible this would be, nor how much work it would involve. It would be a less convenient than what exists now, but it would still be more convenient than trying to put a breakpoint somewhere in your library and potentially waiting until its too late to gather any meaningful information.

What do you think?

In https://reviews.llvm.org/D39307#907253, @jingham wrote:

> Even worse, it would work when I stepped into the code of my library, but then when I stepped out to the client it would stop working. And the error would be just "unknown symbol my_library_singleton". We wouldn't have a good way to help explain this failure


I totally agree. The diagnostics of failure here are in poor, at best. I could modify what we do to say "hey, I found the symbol you're talking about in this module, but it's not visible from this context." If my idea about the flag above sounds good, we could even say "you can use this flag if want to see it here and now".


https://reviews.llvm.org/D39307