<div dir="ltr">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)</div><div dir="ltr"><br></div><div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 10, 2019 at 1:16 PM Petr Penzin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-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" id="gmail_block_quote0">
<div text="#000000" bgcolor="#FFFFFF">
<p>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.</p></div><div text="#000000" bgcolor="#FFFFFF">
<p>-Petr<br>
</p></div><div text="#000000" bgcolor="#FFFFFF">
<div class="m_2652896211030305958m_2050961336865950399moz-cite-prefix">On 1/9/19 6:17 PM, Zachary Turner via
llvm-dev wrote:<br>
</div>
<blockquote type="cite">
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.<br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Jan 9, 2019 at 2:48 PM Shoaib Meenai via
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-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">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.)<br>
<br>
On 1/9/19, 2:07 PM, "llvm-dev on behalf of David Greene via
llvm-dev" <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>
on behalf of <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:<br>
<br>
<br>
David Jones via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
writes:<br>
<br>
> GDB likes to load all symbols from shared libraries
up front. And on<br>
> x86_64 your main executable is really just another
shared library.<br>
<br>
Yes, but does gdb reload everything on each execution?
Every time I<br>
execute "run" I see the same slow behavior. Loading the
symbols for<br>
small tools like llvm-rc takes hardly any time at all
(i.e. "file<br>
llvm-rc" is almost instantaneous). But executing it
causes gdb to chew<br>
up CPU cycles for a while. Every time.<br>
<br>
-David<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="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=" rel="noreferrer" target="_blank">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=</a><br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
<br>
<fieldset class="m_2652896211030305958m_2050961336865950399mimeAttachmentHeader"></fieldset>
<pre class="m_2652896211030305958m_2050961336865950399moz-quote-pre">_______________________________________________
LLVM Developers mailing list
<a class="m_2652896211030305958m_2050961336865950399moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_2652896211030305958m_2050961336865950399moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><span>
</span>