[lldb-dev] Dlopen extremely slow while LLDB is attached

[Pavel Labath via lldb-dev]

On Wed, 25 Apr 2018 at 19:59, Scott Funkenhauser via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

> Thanks Greg and Jason for pointing me in the right direction!

> The results from my original tests were due to a timeout being triggered:

> 1524681484.092825651 (x86_64) /tmp/liblldb.so.7.0.0: Reading EH frame info
> 1524681489.783293724 error: timed out, status = timed out
> 1524681489.783379793 this = 0x00005555573DDC80, timeout = 5000000 us
> 1524681489.840902615 Breakpoint::ModulesChanged: num_modules: 1 load: 1
delete_locations: 0

Hmm... that is strange. Could you also enable the "gdb-remote packets" log
so we can see what is timing out.


> I ran the exact same setup on a few other machines, and none of them hit
the timeout (so not sure what happened with my first test, more
investigation is required). Without the timeout, loading times of a
stripped shared library with LLDB attached was much more reasonable.

> I then ran another test on a shared library that had DWARF sections. I
tracked down the majority of the extra time to be taking place inside
SymbolFileDWARF::Index(), which confirms your theory of the additoinal time
being due to indexing the DWARF sections.

> I found this message (
http://lists.llvm.org/pipermail/llvm-dev/2018-January/120509.html) which
mentioned adding DWARF5 accelerator table support. Is it reasonable to
assume once that is implemented the time it takes to index DWARF sections
should be drastically reduced?

Yes, that is the idea. I got a bit side-tracked the last two weeks, but I
should be back on that project soon. The current state is that the compiler
support is mostly in place, and now I need to add debugger support for
this. (Maybe it's obvious, but you will only get the speed up if you use a
compiler which supports this feature, which will be clang-7 at the
earliest, and you will probably need to pass an extra flag to enable it)