[llvm-dev] Slow debugger starts of LLVM tools

[David Blaikie via llvm-dev]

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>