David Blaikie via llvm-dev
2019-Jan-11 22:08 UTC
[llvm-dev] Slow debugger starts of LLVM tools
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>
David Greene via llvm-dev
2019-Jan-15 16:53 UTC
[llvm-dev] Slow debugger starts of LLVM tools
I was under the impression that a generated gdb-index only helps when
loading the file ('file foo' in gdb). Does it help execution startup
time as well?
I'll give it a try and see if it helps. Thanks all!
-David
David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> writes:
> 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 list
> llvm-dev at lists.llvm.org
> http://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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
David Blaikie via llvm-dev
2019-Jan-16 00:45 UTC
[llvm-dev] Slow debugger starts of LLVM tools
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? On Wed, Jan 16, 2019 at 3:53 AM David Greene <dag at cray.com> wrote:> I was under the impression that a generated gdb-index only helps when > loading the file ('file foo' in gdb). Does it help execution startup > time as well? > > I'll give it a try and see if it helps. Thanks all! > > -David > > David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > 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 list > > llvm-dev at lists.llvm.org > > http://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 > > > > _______________________________________________ > > 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/20190116/fde7c294/attachment.html>