[lldb-dev] [BUG] Many lookup failures

[David Blaikie via lldb-dev]

On Mon, 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.
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151130/7ef47d81/attachment-0001.html>