<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 1, 2015 at 2:11 AM David Blaikie via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 30, 2015 at 6:04 PM, Ramkumar Ramachandra <span dir="ltr"><<a href="mailto:artagnon@gmail.com" target="_blank">artagnon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Mon, Nov 30, 2015 at 5:42 PM, Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br>
> 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.<br>
<br>
</span>Tangential: gdb starts up significantly faster than lldb. I wonder<br>
what lldb is doing wrong.<br>
<br>
Oh, this is if I use the lldb that Apple supplied. If I compile my own<br>
lldb with llvm-release, clang-release, and lldb-release, it takes like<br>
20x the time to start up: why is this? And if I use llvm-debug,<br>
clang-debug, lldb-debug, the time it takes is completely unreasonable.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> 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.<br>
<br>
</span>Yeah, about that. I question the utility of evaluating crazy<br>
expressions in lldb: I've not felt the need to do that even once, and<br>
I suspect a large userbase is with me on this. What's important is<br>
that lldb should _never_ fail to inspect a variable: isn't this the #1<br>
job of the debugger?<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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))<br></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>- Dave</div></div></div></div>
_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br>
</blockquote></div></div>