[llvm-dev] Slow debugger starts of LLVM tools (original) (raw)

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 15 16:45:55 PST 2019

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 > > x8664 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. > orgcgi-2Dbinmailmanlistinfollvm-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>

More information about the llvm-dev mailing list