[lldb-dev] [BUG] Many lookup failures

[Tamas Berghammer via lldb-dev]

On Tue, Dec 1, 2015 at 2:11 AM David Blaikie via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

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

What do you mean under startup speed and how do you measure it? I use
Release+Assert build of ToT LLDB on Linux and it takes significantly less
time for it to start up when debugging a large application (I usually test
with debug clang) then what you mentioned.

For me just to start up LLDB is almost instantaneous (~100ms) as it don't
parse any symbol or debug information at that time. If I trigger some debug
info parsing/indexing (with setting a breakpoint) then the startup time
will be around 3-5 seconds (40 core + ssd machine) what include an indexing
of all DIEs (it should be faster on darwin as the index is already in the
executable). On the other hand doing the same with gdb takes ~30 seconds
(independently if I set a breakpoint or not) because gdb parses all symbol
info at startup.

I would like to understand why are you seeing so slow startup time as I
worked on optimizing symbol parsing quite a bit in the last few month. Can
you send me some information about how you measure the startup time (lldb
commands, some info about the inferior) and can you do a quick profiling to
see where the time is spent?


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

If you just want to inspect the content of a variable then I suggest to use
the "frame variable" command as it require significantly less context then
evaluating an expression. Unfortunately it can still fail in some cases
with the same lookup failure you see but it happens in significantly less
cases.


> - Dave
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151201/f5f04d9a/attachment.html>