[lldb-dev] [BUG] Many lookup failures

[Ramkumar Ramachandra via lldb-dev]

On Mon, Nov 30, 2015 at 5:42 PM, Greg Clayton <gclayton at 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?