我正在尝试调试我写的C++程序,但当我在LLDB中运行它并停止程序时,它只显示汇编代码,而不是原始源代码。 例如,在崩溃后我想要调试:
Process 86122 stopped
* thread #13: tid = 0x142181, 0x0000000100006ec1 debug_build`game::update() + 10961, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x0000000100006ec1 debug_build`game::update() + 10961
debug_build`game::update:
-> 0x100006ec1 <+10961>: movq (%rdx), %rdx
0x100006ec4 <+10964>: movq %rax, -0xb28(%rbp)
0x100006ecb <+10971>: movq -0x1130(%rbp), %rax
0x100006ed2 <+10978>: movq 0x8(%rax), %rsi
我正在使用-O0 -g
编译。当我通过Xcode(我在OSX上)或从命令行运行调试器时,我看到相同的情况。
我还需要做什么才能让源代码出现在LLDB中?
附加说明
这是典型构建命令的示例:
clang++ -std=c++1y -stdlib=libc++ -fexceptions -I/usr/local/include -c -O2 -Wall -ferror-limit=5 -g -O0 -ftrapv lib/format.cpp -o format.o
之前有 -O2
,因为我使用的是默认值,但我认为后面的 -O0
会覆盖它,对吗?
我尝试过
我用同样的构建设置创建了一个简单的“hello world”程序来重现这个问题。
经过一些搜索,我尝试运行
dsymutil main.o
,它显示warning: no debug symbols in executable (-arch x86_64)
,所以也许我的构建命令没有生成调试符号?我还尝试将
-gsplit-dwarf
添加到构建命令中,但没有效果。这是我“hello world”版本的链接命令:
clang++ main.o -L/usr/local/lib -g -o hello
我在可执行文件和目标文件上运行了
dwarfdump
(我在这里读到的)。在我的生疏的眼中,它看起来像调试符号在目标文件中是存在的,但在可执行文件本身中不存在(除非dwarfdump
只能在目标文件上工作,这是可能的)。所以也许连接阶段存在问题。或者可能出现了 DWARF 的问题。现在,我已经通过在终端逐个发出构建命令来在“hello world”程序中解决了这个问题。因此,我猜这可能是我的构建系统(Tup)的问题,可能会以不同的工作目录运行命令,因此路径会出现问题或其他什么问题。
dwarfdump
与各种基于Tup和非Tup构建命令,并且似乎它正在搞乱DWARF输出中的路径。Tup使用一个虚拟的FUSE文件系统来确定构建命令的输出,所以很可能是这个原因。我会进一步更新这个问题,并在找到答案时提供一个解决方案。如果有人看到这篇文章并知道Tup的解决方案,请让我知道,但我知道这是一个不太知名的工具。 - Leo