<div dir="ltr">Ah, yeah, I haven't observed particularly long program startup time. Could you time it & specify exxactly which commands (both the command you used to start gdb, and the commands you executed in gdb) you executed/which ones took a long time/roughly how long they took, etc?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 16, 2019 at 3:53 AM David Greene <<a href="mailto:dag@cray.com">dag@cray.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was under the impression that a generated gdb-index only helps when<br>
loading the file ('file foo' in gdb). Does it help execution startup<br>
time as well?<br>
<br>
I'll give it a try and see if it helps. Thanks all!<br>
<br>
-David<br>
<br>
David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> writes:<br>
<br>
> Yep, as others have mentioned - using a linker-generated gdb-index is<br>
> super helpful (10s for my machine to start debugging an unoptimized<br>
> clang, set a breakpoint at llvm::StringRef::StringRef and run until<br>
> that breakpoint is hit, as opposed to 1m26s without an index)<br>
><br>
> That's also with/without split DWARF too, but I suspect most of the<br>
> benefit is in the index there. Split DWARF might save you some linking<br>
> time and /maybe/ some debugger performance.<br>
><br>
> On Thu, Jan 10, 2019 at 1:16 PM Petr Penzin via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I've ran into the same issue before. I tend to see it as a<br>
> price we pay for static linking, since it brings all the symbols<br>
> debugger has to read at the start time. Quick check on launching a<br>
> tool (fort) in GDB (I usually use it) and LLDB shows that LLDB<br>
> starts much faster, but takes time to set breakpoints and launch<br>
> the application, so I think they are roughly on the same page in<br>
> terms of delays.<br>
><br>
> -Petr<br>
> <br>
> <br>
> On 1/9/19 6:17 PM, Zachary Turner via llvm-dev wrote:<br>
> <br>
> This is admittedly a longshot, but Can you check whether you<br>
> experience unusually long run times with LLDB? If there’s<br>
> something strange about tge binaries we generate, maybe lldb<br>
> will exhibit some strangeness too and we can more easily<br>
> profile it.<br>
> <br>
> <br>
> On Wed, Jan 9, 2019 at 2:48 PM Shoaib Meenai via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> I don't know about the issues with running being slow, but<br>
> using a GDB index greatly speeds up initial symbol<br>
> loading. Compile with `-ggnu-pubnames` and link with<br>
> `-Xlinker --gdb-index` and you should get significantly<br>
> faster symbol load times. (I'd be curious to see if it<br>
> 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<br>
> via llvm-dev" <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a> on behalf<br>
> 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<br>
> front. And on<br>
> > x86_64 your main executable is really just another<br>
> shared library.<br>
> <br>
> Yes, but does gdb reload everything on each execution?<br>
> Every time I<br>
> execute "run" I see the same slow behavior. Loading the<br>
> symbols for<br>
> small tools like llvm-rc takes hardly any time at all<br>
> (i.e. "file<br>
> llvm-rc" is almost instantaneous). But executing it causes<br>
> 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" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm</a>.<br>
> org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=dqw6dQj2Nwimdo2WZ3P_<br>
> n0WRZBWrrtNACdQfXzCB0Xc&s=psETNIS-WHrFqc7U8d3tg6i1UGx4-CHNUo0FO-<br>
> FNQJg&e=<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>
><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>
><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>
><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>