<div dir="ltr"><br><div class="gmail_extra"><br><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 class="">On Mon, Nov 30, 2015 at 5:42 PM, Greg Clayton <<a href="mailto:gclayton@apple.com">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>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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><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>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><br>- Dave</div></div></div></div>