[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#907301, @jingham wrote:

> So one of the expectations of people using the debugger is that their whole program is available to them wherever they happen to be stopped.  People get really upset when we break that fiction.  I've experienced this both in Radar and in person...  But in this case, it seems like a reasonable expectation:
>
> Imagine the debugging scenario where I had stepped into my library, run my debugging function, stepped out to the client and what got returned didn't make sense with the output of the debugging function.  So I want to run it again to see what happened.  I certainly don't want to have to navigate back to my library to do that, I don't want the program to change state at all and there may be no functions of my library still on the stack somewhere.
>
> I think if you make me say:
>
>   (lldb) expr --pretend-module MyLib.dyld -- my_library_singleton->WFTDude()
>  
>
>
> you will not make me happy.  lldb should not force users to disambiguate things that are not ambiguous.  If there were multiple visible my_library_singleton symbols floating around, that would be my fault for choosing a bad name, and as the debugger user I wouldn't feel too bad about having to do something to disambiguate.  But if it isn't lldb shouldn't make me have to do more work to specify it.


I think that the problem here is that lldb is disambiguating and grabbing internal symbols from libraries I don't want it to. It seems like clang shouldn't even be asking us about this in the first place, but I don't fully understand why it's trying to do what it's trying to do. Perhaps somebody with more understanding of what clang should be doing can shine some light?


https://reviews.llvm.org/D39307