符号加载非常缓慢

Question

我最近发现gdb在执行目标应用程序的代码之前需要很长时间。我无法弄清原因。我使用的是MacOS 10.6.5和GNU gdb 6.3.50-20050815（Apple版本gdb-1510）。

如果我用CTRL-C打断它，我可以从回溯输出中看到以下内容。看起来它卡在了加载符号？

无论如何，我对gdb的内部工作方式不太熟悉。有人能为我提供一个提示来改善这种情况吗？

#0  0x00007fff5fc05136 in __dyld__ZN4dyldL10loadPhase5EPKcRKNS_11LoadContextEPSt6vectorIS1_SaIS1_EE ()
#1  0x00007fff5fc0523f in __dyld__ZN4dyldL10loadPhase4EPKcRKNS_11LoadContextEPSt6vectorIS1_SaIS1_EE ()
#2  0x00007fff5fc0599e in __dyld__ZN4dyldL10loadPhase3EPKcRKNS_11LoadContextEPSt6vectorIS1_SaIS1_EE ()
#3  0x00007fff5fc05a47 in __dyld__ZN4dyldL10loadPhase1EPKcRKNS_11LoadContextEPSt6vectorIS1_SaIS1_EE ()
#4  0x00007fff5fc05b65 in __dyld__ZN4dyldL10loadPhase0EPKcRKNS_11LoadContextEPSt6vectorIS1_SaIS1_EE ()
#5  0x00007fff5fc05bf0 in __dyld__ZN4dyld4loadEPKcRKNS_11LoadContextE ()
#6  0x00007fff5fc06a5d in __dyld__ZN4dyldL14libraryLocatorEPKcbS1_PKN11ImageLoader10RPathChainE ()
#7  0x00007fff5fc0c746 in __dyld__ZN11ImageLoader22recursiveLoadLibrariesERKNS_11LinkContextEbRKNS_10RPathChainE ()
#8  0x00007fff5fc0c66f in __dyld__ZN11ImageLoader22recursiveLoadLibrariesERKNS_11LinkContextEbRKNS_10RPathChainE ()
#9  0x00007fff5fc0c66f in __dyld__ZN11ImageLoader22recursiveLoadLibrariesERKNS_11LinkContextEbRKNS_10RPathChainE ()
#10 0x00007fff5fc0c7b6 in __dyld__ZN11ImageLoader4linkERKNS_11LinkContextEbbRKNS_10RPathChainE ()
#11 0x00007fff5fc04d48 in __dyld__ZN4dyld4linkEP11ImageLoaderbRKNS0_10RPathChainE ()
#12 0x00007fff5fc068d6 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#13 0x00007fff5fc016d2 in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKcl ()
#14 0x00007fff5fc01052 in __dyld__dyld_start ()

- Daniel

---

你尝试过静态链接并比较结果了吗（GCC选项“-static”）？ - Kerrek SB

这并不能解决问题，但是"man dyld"会给你一些选项。尝试设置DYLD_PRINT_STATISTICS环境变量，以查看它在哪里花费时间。 - David Koski

Answer 1

我认为这是由于在gdb代码中重复设置/恢复信号处理程序引起的。当我使用

ptrace -p

我得到了匹配系统调用的页面...

rt_sigaction(SIGSEGV, {SIG_DFL, [], SA_RESTORER, 0x3bfc60f710}, NULL, 8) = 0 rt_sigaction(SIGSEGV, {0x68a820, [], SA_RESTORER|SA_STACK, 0x3bfc60f710}, {SIG_DFL, [], SA_RESTORER, 0x3bfc60f710}, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigaction(SIGSEGV, {SIG_DFL, [], SA_RESTORER, 0x3bfc60f710}, NULL, 8) = 0 rt_sigaction(SIGSEGV, {0x68a820, [], SA_RESTORER|SA_STACK, 0x3bfc60f710}, {SIG_DFL, [], SA_RESTORER, 0x3bfc60f710}, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigaction(SIGSEGV, {SIG_DFL, [], SA_RESTORER, 0x3bfc60f710}, NULL, 8) = 0 rt_sigaction(SIGSEGV, {0x68a820, [], SA_RESTORER|SA_STACK, 0x3bfc60f710}, {SIG_DFL, [], SA_RESTORER, 0x3bfc60f710}, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigaction(SIGSEGV, {SIG_DFL, [], SA_RESTORER, 0x3bfc60f710}, NULL, 8) = 0 rt_sigaction(SIGSEGV, {0x68a820, [], SA_RESTORER|SA_STACK, 0x3bfc60f710}, {SIG_DFL, [], SA_RESTORER, 0x3bfc60f710}, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigaction(SIGSEGV, {SIG_DFL, [], SA_RESTORER, 0x3bfc60f710}, NULL, 8) = 0 rt_sigaction(SIGSEGV, {0x68a820, [], SA_RESTORER|SA_STACK, 0x3bfc60f710}, {SIG_DFL, [], SA_RESTORER, 0x3bfc60f710}, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0

- user12411795