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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
