llvm dev - Jan 2019 - 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>

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>

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>