On Mon, Nov 30, 2015 at 6:04 PM, Ramkumar Ramachandra <artag...@gmail.com> wrote:
> On Mon, Nov 30, 2015 at 5:42 PM, Greg Clayton <gclay...@apple.com> wrote: > > When we debug "a.out" again, we might have recompiled "liba.so", but not > "libb.so" and when we debug again, we don't need to reload the debug info > for "libb.so" if it hasn't changed, we just reload "liba.so" and its debug > info. When we rerun a target (run a.out again), we don't need to spend any > time reloading any shared libraries that haven't changed since they are > still in our global shared library cache. So to keep this global library > cache clean, we don't allow types from another shared library (libb.so) to > be loaded into another (liba.so), otherwise we wouldn't be able to reap the > benefits of our shared library cache as we would always need to reload > debug info every time we run. > > Tangential: gdb starts up significantly faster than lldb. I wonder > what lldb is doing wrong. > > Oh, this is if I use the lldb that Apple supplied. If I compile my own > lldb with llvm-release, clang-release, and lldb-release, it takes like > 20x the time to start up: why is this? And if I use llvm-debug, > clang-debug, lldb-debug, the time it takes is completely unreasonable. > If you built your own you probably built a +Asserts build which slows things down a lot. You'll want to make sure you're building Release-Asserts (Release "minus" Asserts) builds if you want them to be usable. > > > LLDB currently recreates types in a clang::ASTContext and this imposes > much stricter rules on how we represent types which is one of the > weaknesses of the LLDB approach to type representation as the clang > codebase often asserts when it is not happy with how things are > represented. This does payoff IMHO in the complex expressions we can > evaluate where we can use flow control, define and use C++ lambdas, and > write more than one statement when writing expressions. But it is > definitely a tradeoff. GDB has its own custom type representation which can > be better for dealing with the different kinds and completeness of debug > info, but I am comfortable with our approach. > > Yeah, about that. I question the utility of evaluating crazy > expressions in lldb: I've not felt the need to do that even once, and > I suspect a large userbase is with me on this. What's important is > that lldb should _never_ fail to inspect a variable: isn't this the #1 > job of the debugger? > Depends on the language - languages with more syntactic sugar basically need crazy expression evaluation to function very well in a debugger for the average user. (evaluating operator overloads in C++ expressions, just being able to execute non-trivial pretty-printers for interesting types (std::vector being a simple example, or a small-string optimized std::string, etc - let alone examples in ObjC or even Swift)) - Dave
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev