[llvm-dev] Slow debugger starts of LLVM tools

[David Blaikie via llvm-dev]

Yep, as others have mentioned - using a linker-generated gdb-index is super
helpful (10s for my machine to start debugging an unoptimized clang, set a
breakpoint at llvm::StringRef::StringRef and run until that breakpoint is
hit, as opposed to 1m26s without an index)

That's also with/without split DWARF too, but I suspect most of the benefit
is in the index there. Split DWARF might save you some linking time and
/maybe/ some debugger performance.

On Thu, Jan 10, 2019 at 1:16 PM Petr Penzin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I've ran into the same issue before. I tend to see it as a price we pay
> for static linking, since it brings all the symbols debugger has to read at
> the start time. Quick check on launching a tool (fort) in GDB (I usually
> use it) and LLDB shows that LLDB starts much faster, but takes time to set
> breakpoints and launch the application, so I think they are roughly on the
> same page in terms of delays.
>
> -Petr
> On 1/9/19 6:17 PM, Zachary Turner via llvm-dev wrote:
>
> This is admittedly a longshot, but Can you check whether you experience
> unusually long run times with LLDB? If there’s something strange about tge
> binaries we generate, maybe lldb will exhibit some strangeness too and we
> can more easily profile it.
> On Wed, Jan 9, 2019 at 2:48 PM Shoaib Meenai via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I don't know about the issues with running being slow, but using a GDB
>> index greatly speeds up initial symbol loading. Compile with
>> `-ggnu-pubnames` and link with `-Xlinker --gdb-index` and you should get
>> significantly faster symbol load times. (I'd be curious to see if it helps
>> with the issues with run being slow as well.)
>>
>> On 1/9/19, 2:07 PM, "llvm-dev on behalf of David Greene via llvm-dev" <
>> llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org>
>> wrote:
>>
>>
>>     David Jones via llvm-dev <llvm-dev at lists.llvm.org> writes:
>>
>>     > GDB likes to load all symbols from shared libraries up front. And on
>>     > x86_64 your main executable is really just another shared library.
>>
>>     Yes, but does gdb reload everything on each execution?  Every time I
>>     execute "run" I see the same slow behavior.  Loading the symbols for
>>     small tools like llvm-rc takes hardly any time at all (i.e. "file
>>     llvm-rc" is almost instantaneous).  But executing it causes gdb to
>> chew
>>     up CPU cycles for a while.  Every time.
>>
>>                              -David
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     llvm-dev at lists.llvm.org
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=dqw6dQj2Nwimdo2WZ3P_n0WRZBWrrtNACdQfXzCB0Xc&s=psETNIS-WHrFqc7U8d3tg6i1UGx4-CHNUo0FO-FNQJg&e=
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190112/cfe7eb49/attachment.html>