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

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

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=

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>