[lldb-dev] [BUG] Many lookup failures

[Greg Clayton via lldb-dev]

> On Nov 30, 2015, at 6:04 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote:
> 
> 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.

LLDB loads all shared libraries that it can when it first launches and GDB doesn't. In GDB you pay for this when you run your program. So if you want to compare things, do something like:

- get the current time as time1
- set an executable file in GDB and LLDB
- set a breakpoint
- run and hit the breakpoint
- get the current time as time2 and subtract from time1 and note time measurement.

Load GDB and LLDB up with a nice fat clang with debug info and the time to run to a breakpoint as a nice example. 

> 
> 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?

Not sure one this. 

Are you saying you build on MacOSX using the Xcode project and build the "Release" build configuration and it runs slower than the LLDB that is shipped by Apple? This shouldn't happen. One reason that this might be the case is the binaries you build are not stripped and have a TON of C++ names that are not exported through the LLDB.framework, but are in the symbol table. You can run "strip -Sx" on your LLDB.framework and it should remove these extra symbols.


> And if I use llvm-debug,
> clang-debug, lldb-debug, the time it takes is completely unreasonable.

Simple: optimized code is much faster

> 
>> 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?

I agree with you on this. "frame variable" should never fail you as it doesn't use the expression parser. "frame variable" and its rock solid functionality is what IDEs use to display variables in variable views. So use "frame variable" and all will be good.

The expression parser is more complex and requires some special handling due to how we represent the ASTs as a single AST for all compile units within a module (executable/shared library). We use clang as the expression parser and this won't change so even if we tried to limit the expression parser to only do what the GDB expression parser does it won't help. So we need to tame the beast and we need to track down why things are not evaluating correctly when they do go wrong.

So please help us to track any issues down that we are having as one bug fix can often lead to fixing a whole variety of different issues.