Rafael Avila de Espindola via llvm-dev
2017-Nov-27 17:50 UTC
[llvm-dev] [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
Martin Richtarsky via llvm-dev
2017-Nov-28 14:40 UTC
[llvm-dev] [LLD] Slow callstacks in gdb
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/
Rafael Avila de Espindola via llvm-dev
2017-Nov-28 17:46 UTC
[llvm-dev] [LLD] Slow callstacks in gdb
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