我是LLDB的新手(嗯,实际上是大多数命令行工具的新手)。当我跟踪这个非常easy and helpful article回溯段故障错误时,我发现使用LLDB在Mac OS X 10.10上的输出与使用gdb作为调试器的作者的输出不同。
使问题更清楚。
在我使用lldb在上面的文章中运行相同的代码后,遇到了段错误错误,并使用了lldb的bt
命令,我得到了这条消息。
* thread #1: tid = 0x208541, 0x00007fff8869a05a libsystem_platform.dylib`_platform_memmove$VARIANT$Unknown + 186, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
* frame #0: 0x00007fff8869a05a libsystem_platform.dylib`_platform_memmove$VARIANT$Unknown + 186
frame #1: 0x00007fff8fc08866 libsystem_c.dylib`fgets + 243
frame #2: 0x0000000100000f34 sf`main + 68
frame #3: 0x00007fff8e6535c9 libdyld.dylib`start + 1
由于我将可执行文件命名为“sf”(段错误的简称),因此我按照文章中的想法使用了f 2
命令。
现在出了问题,因为我收到了这条消息。
frame #2: 0x0000000100000f34 sf`main + 68
sf`main:
0x100000f34 <+68>: leaq 0x5f(%rip), %rdi ; "%s\n"
0x100000f3b <+75>: movq -0x18(%rbp), %rsi
0x100000f3f <+79>: movq %rax, -0x20(%rbp)
0x100000f43 <+83>: movb $0x0, %al
它似乎是汇编语言,与gdb提供的C语言相比实际上没有帮助,如上文所示,它是:
#3 0x80484b2 in main (argc=1, argv=0xbffffaf4) at segfault.c:10
10 fgets(buf, 1024, stdin)
所以我的问题是我可以使用LLDB获得C语言回溯吗?
答案 0 :(得分:2)
编译时需要添加-g
标志。另外,我建议使用-O0
标志,它告诉编译器执行最小的优化。通过更积极的优化,您可以在调试器中获得奇怪的行为。通常当我尝试跟踪seg故障和类似错误时,我发现条件断点和观察点是最有用的命令。您可以通过执行breakpoint set --file <filename> --line <line number> --condition '<some C expression>'
在行号处设置条件断点。可以使用w s e -- <address>
设置观察点,其中<address>
是要观看的位置。