jingham added a comment. 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. https://reviews.llvm.org/D39307 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
