llvm dev - Jan 2019 - Slow debugger starts of LLVM tools

I'm wondering if anyone else is running into this problem.

When I do a Debug build and attempt to run a tool (opt, llvm-dis,
whatever) in gdb, the program takes a LOOOOONG time to begin executing.
Loading the executable into gdb is not the problem.  I type "run" and
the debugger sits there for many seconds and then things start going.
gdb emits no messages indicating what it is doing but it's basically
using 100% CPU.

I'm wondering if this is an artifact of the gdb I'm using (buggy?) or
something inherent to the way LLVM tools are built.  I see the same slow
operation across different versions of gdb and I do not see the same
slow operation with other executables.

                         -David

On Thu, Jan 10, 2019 at 12:28 AM David Greene via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> I'm wondering if anyone else is running into this problem.
>
> When I do a Debug build and attempt to run a tool (opt, llvm-dis,
> whatever) in gdb, the program takes a LOOOOONG time to begin executing.
> Loading the executable into gdb is not the problem.  I type "run"
and
> the debugger sits there for many seconds and then things start going.
> gdb emits no messages indicating what it is doing but it's basically
> using 100% CPU.
I do see such perf issues, although i *think* for me they happen
when initially loading the executable in gdb, and the 'run' itself works
fast.
> I'm wondering if this is an artifact of the gdb I'm using (buggy?)
or
> something inherent to the way LLVM tools are built.  I see the same slow
> operation across different versions of gdb and I do not see the same
> slow operation with other executables.
It probably has the same source as the Release vs Debug filesize -
debug info for LLVM is *big*.
(It would be interesting to know if there is a solution, other than
using lldb of course.)
>                          -David
Roman.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

GDB likes to load all symbols from shared libraries up front. And on x86_64
your main executable is really just another shared library.

So yes, it's slow. The sloth is proportional to the size of the object(s)
being debugged. It's not just LLVM, it's any large (i.e. 100+MB to 1+GB)
executable+library footprint.


On Wed, Jan 9, 2019 at 4:28 PM David Greene via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I'm wondering if anyone else is running into this problem.
>
> When I do a Debug build and attempt to run a tool (opt, llvm-dis,
> whatever) in gdb, the program takes a LOOOOONG time to begin executing.
> Loading the executable into gdb is not the problem.  I type "run"
and
> the debugger sits there for many seconds and then things start going.
> gdb emits no messages indicating what it is doing but it's basically
> using 100% CPU.
>
> I'm wondering if this is an artifact of the gdb I'm using (buggy?)
or
> something inherent to the way LLVM tools are built.  I see the same slow
> operation across different versions of gdb and I do not see the same
> slow operation with other executables.
>
>                          -David
> _______________________________________________
> 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/00b920a6/attachment.html>

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