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