> This is a known issue, though I did not expect it to have that much of an
> impact. In fact, I have trouble reconciling this fact with your earlier
> statement that second and subsequent runs are much faster. The SO entry
> loading is something that has to happen on every run, so I don't see why
On Mon, 30 Apr 2018 at 20:13, Scott Funkenhauser
wrote:
> I messed up my test setup and incorrectly attributed the additional time.
Parsing the DWARF sections does add additional time, but only increases by
a small percentage.
> By pure chance I noticed that the latency between the client and se
I messed up my test setup and incorrectly attributed the additional time.
Parsing the DWARF sections does add additional time, but only increases by
a small percentage.
By pure chance I noticed that the latency between the client and server had
a huge impact. I did some tests against lldb_server r
On Wed, 25 Apr 2018 at 19:59, Scott Funkenhauser via lldb-dev <
lldb-dev@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: Readi
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 =
> On Apr 24, 2018, at 12:26 PM, Scott Funkenhauser via lldb-dev
> wrote:
>
> Hey guys,
>
> I'm trying to track down an issue I'm seeing where dlopen takes significantly
> longer to execute when LLDB is attached vs GDB (I've attached a simple
> program that I used to reproduce the issue).
>
No liblldb.so didn't have any debug information, I made sure to strip it.
With debug information it was 1.7GB which took way too long to load for a
practical reproduction case.
On Tue, Apr 24, 2018 at 3:36 PM Jason Molenda wrote:
> Was liblldb.so build with debug information? You're probably lo
Was liblldb.so build with debug information? You're probably looking at lldb
scanning the DWARF to make up its symbol table. That would be re-used on
subsequent reruns so you're only seeing the cost that first time through. gdb
may be using the standard dwarf accelerator tables, or it may be
