llvm dev - Nov 2017 - [LLD] Slow callstacks in gdb

Is the program being built by gcc or clang?

Cheers,
Rafael

Rafael Avila de Espindola <rafael.espindola at gmail.com> writes:
> Martin Richtarsky via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
>> Hi,
>>
>> for programs linked with lld it's substantially slower to get
callstacks
>> in gdb, in comparison to gold-linked programs. Two measurements:
>>
>> lld     gold
>> 15 sec  3 sec
>> 6 sec   2 sec
>
> Are both using --gdb-index? Can you try lld trunk if so?
>
> Is any of the programs you tested open source?
>
> Cheers,
> Rafael

Hi,
> Is the program being built by gcc or clang?
gcc 6, but I can try clang.
> Are both using --gdb-index? Can you try lld trunk if so?
No.
> Is any of the programs you tested open source?
No.

Here is some more info. I enabled "set verbose on" in gdb. With this
setting, I'm getting DWARF errors in both versions when executing
"bt"
(linked by gold and lld), but the lld version has significantly more
errors. These only appear in the lld version:

(gdb) bt
Reading in symbols for abc.cpp....
debug_line address at offset 0x575128 is 0 [in module abc.so]....
debug_line address at offset 0x575141 is 0 [in module abc.so]....
cannot get low and high bounds for subprogram DIE at 52844002...
cannot get low and high bounds for subprogram DIE at 52844042...
cannot get low and high bounds for subprogram DIE at 52844092...
const value length mismatch for 'std::ios_constants::boolalpha', got 4,
expected 0
debug info gives command-line macro definition with non-zero line 13: __MACRO
macro '__USE_ISOC95' is #undefined twice
macro `__STDC_LIMIT_MACROS' redefined at...
Member function "~basic_istream" (offset 28792309) is virtual but the
vtable offset is not specified...



Maybe gdb needs to fall back to slower line number resolution because e.g.
low and high bounds cannot be retrieved and debug_line_address is 0?

Best regards,
Martin

Rafael Avila de Espindola schrieb:
> Is the program being built by gcc or clang?
>
> Cheers,
> Rafael
>
> Rafael Avila de Espindola <rafael.espindola at gmail.com> writes:
>
>> Martin Richtarsky via llvm-dev <llvm-dev at lists.llvm.org>
writes:
>>
>>> Hi,
>>>
>>> for programs linked with lld it's substantially slower to get
>>> callstacks
>>> in gdb, in comparison to gold-linked programs. Two measurements:
>>>
>>> lld     gold
>>> 15 sec  3 sec
>>> 6 sec   2 sec
>>
>> Are both using --gdb-index? Can you try lld trunk if so?
>>
>> Is any of the programs you tested open source?
>>
>> Cheers,
>> Rafael
>
>

-- 
http://www.productive-cpp.com/

Martin Richtarsky <s at martinien.de> writes:
> Hi,
>
>> Is the program being built by gcc or clang?
> gcc 6, but I can try clang.
>
>> Are both using --gdb-index? Can you try lld trunk if so?
> No.
>
>> Is any of the programs you tested open source?
> No.
>
> Here is some more info. I enabled "set verbose on" in gdb. With
this
> setting, I'm getting DWARF errors in both versions when executing
"bt"
> (linked by gold and lld), but the lld version has significantly more
> errors. These only appear in the lld version:
>
> (gdb) bt
> Reading in symbols for abc.cpp....
> debug_line address at offset 0x575128 is 0 [in module abc.so]....
> debug_line address at offset 0x575141 is 0 [in module abc.so]....
> cannot get low and high bounds for subprogram DIE at 52844002...
> cannot get low and high bounds for subprogram DIE at 52844042...
> cannot get low and high bounds for subprogram DIE at 52844092...
> const value length mismatch for 'std::ios_constants::boolalpha',
got 4,
> expected 0
> debug info gives command-line macro definition with non-zero line 13:
__MACRO
> macro '__USE_ISOC95' is #undefined twice
> macro `__STDC_LIMIT_MACROS' redefined at...
> Member function "~basic_istream" (offset 28792309) is virtual but
the
> vtable offset is not specified...
>
>
>
> Maybe gdb needs to fall back to slower line number resolution because e.g.
> low and high bounds cannot be retrieved and debug_line_address is 0?
It is hard to know without a reproducible. I tried gdb on clang itself
build with both clang and gcc and linked with gold and lld. I could not
reproduce the slowdown, but I was using trunk lld.

Cheers,
Rafael