Zachary Turner via llvm-dev
2019-Jan-10 02:17 UTC
[llvm-dev] Slow debugger starts of LLVM tools
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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190109/e7159961/attachment.html>
Petr Penzin via llvm-dev
2019-Jan-10 03:16 UTC
[llvm-dev] Slow debugger starts of LLVM tools
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 <mailto: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 > <mailto:llvm-dev-bounces at lists.llvm.org> on behalf of > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > David Jones via llvm-dev <llvm-dev at lists.llvm.org > <mailto: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 <mailto: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 <mailto: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/20190109/ce0c4105/attachment.html>
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>