LLDB没有显示源代码 [英] LLDB not showing source code

问题描述

我正在尝试调试正在编写的C ++程序，但是当我在LLDB中运行它并停止该程序时，它仅显示汇编程序，而不显示原始源代码. 例如崩溃之后，我正在尝试调试:

I am trying to debug a C++ program I am writing, but when I run it in LLDB and stop the program, it only shows me the assembler, not the original source. e.g. after the crash I’m trying to debug:

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上)或从命令行运行调试器时，我会看到相同的东西.

I am compiling with -O0 -g. I see the same thing when running the debugger via Xcode (I’m on OSX) or from the command line.

我还需要做些什么才能使源代码显示在LLDB中?

What else might I need to do to get the source code to show up in LLDB?

附加说明

这是典型的构建命令的示例:

Here is an example of a typical build command:

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会覆盖它，对吧?

The earlier -O2 is there because that’s the default I’m using, but I believe the later -O0 overrides it, right?

我尝试过的事情

1. 我已经使用一个简单的"hello world"程序使用相同的构建设置来重新创建此问题.

1. I’ve recreated this problem with a simple ‘hello world’ program using the same build settings.

在进行一些搜索之后，我尝试运行dsymutil main.o并表示warning: no debug symbols in executable (-arch x86_64)，所以也许构建命令未生成调试符号?

After some searching, I tried running dsymutil main.o which said warning: no debug symbols in executable (-arch x86_64), so perhaps the debug symbols are not being generated by my build commands?

我还尝试将-gsplit-dwarf添加到构建命令中，但没有任何效果.

I also tried adding -gsplit-dwarf to the build commands but with no effect.

这是我的"hello world"版本中的链接命令:

Here is the link command from my ‘hello world’ version:

clang ++ main.o -L/usr/local/lib -g -o hello

clang++ main.o -L/usr/local/lib -g -o hello

我运行了dwarfdump(我阅读了有关此内容)，请参见可执行文件和目标文件.在我看来，未经培训的人看起来像调试符号 存在于目标文件中，而不是存在于可执行文件本身中(除非dwarfdump仅适用于目标文件，这是可能的).因此，也许是链接阶段是问题所在.也许DWARF有问题.

I ran dwarfdump (I read about it here) on the executable and object files. It looks to my untrained eye like the debug symbols are present in the object files, but not in the executable itself (unless dwarfdump only works on object files, which is possible). So maybe the linking stage is the issue. Or maybe there’s a problem with the DWARF.

现在，通过在终端中一次发出构建命令，我已经在"hello world"程序中完成了此工作.因此，我猜测这可能是我的构建系统( Tup )的问题，可能是在其他命令下运行了工作目录，这样路径就变得混乱了.

I have now got this working in the ‘hello world’ program, through issuing build commands one-by-one in the terminal. I am therefore guessing this may be an issue with my build system (Tup), possibly running the commands with a different working directory so the paths get mangled or something.

推荐答案

将-g命令行选项添加到clang时，DWARF调试信息将放置在.o文件中.当您将目标文件(.o，ranlib归档文件，也称为静态库，也称为.a文件)链接到可执行文件/dylib/framework/bundle中时，调试注释"会放入可执行文件中，以表示(1) .o etc文件，其中包含调试信息，以及(2)可执行二进制文件中的函数/变量的最终地址.优化标志(-O0，-O2等)对调试信息的生成没有影响-尽管使用优化编译的调试代码比在-O0上构建的调试代码困难得多.

When you add the -g command line option to clang, DWARF debug information is put in the .o file. When you link your object files (.o, ranlib archives aka static libraries aka .a files) into an executable/dylib/framework/bundle, "debug notes" are put in the executable to say (1) the location of the .o etc files with the debug information, and (2) the final addresses of the functions/variables in the executable binary. Optimization flags (-O0, -O2 etc) do not have an impact on debug information generation - although debugging code compiled with optimization is much more difficult than debugging code built at -O0.

如果在该可执行二进制文件上运行调试器-未经任何其他修改-调试器将从.o etc文件 中读取调试信息，只要它们仍在文件系统中生成可执行文件时，在同一文件路径下 .这样可以快速进行迭代开发-无需任何工具即可读取，更新和输出(大型)调试信息.通过运行nm -pa exename并查找OSO条目(以及其他条目)，可以在可执行文件中看到这些调试说明".这些是stab nlist条目，在可执行文件上运行strip(1)会将其删除.

If you run the debugger on that executable binary -- without any other modification -- the debugger will read the debug information from the .o etc files as long as they're still on the filesystem at the same file path when you built the executable. This makes iterative development quick - no tool needs to read, update, and output the (large) debug information. You can see these "debug notes" in the executable by running nm -pa exename and looking for OSO entries (among others). These are stabs nlist entries and running strip(1) on your executable will remove them.

如果要将所有调试信息(在.o文件中)收集到一个独立的捆绑软件中，则可以在可执行文件上运行dsymutil.这使用调试说明(假设:(1).o文件仍位于其原始位置，并且(2)可执行文件尚未剥离)来创建"dSYM捆绑软件".如果二进制文件是 exename ，则dSYM软件包是 exename.dSYM .当调试器在 exename 上运行时，它将在dSYM软件包的二进制文件旁边查找.如果找不到，它将进行Spotlight搜索以查看dSYM是否在计算机上的Spotlight索引位置.

If you want to collect all of the debug information (in the .o files) into a standalone bundle, then you run dsymutil on the executable. This uses the debug notes (assumptions: (1) the .o files are still in their orig location, and (2) the executable has not been stripped) to create a "dSYM bundle". If the binary is exename, the dSYM bundle is exename.dSYM. When the debugger is run on exename, it will look next to that binary for the dSYM bundle. If not found there, it will do a Spotlight search to see if the dSYM is in a spotlight-indexed location on your computer.

您可以在.o文件或dSYM软件包上运行dwarfdump-它们都具有调试信息. dwarfdump在输出可执行文件中找不到任何调试信息.

You can run dwarfdump on .o files, or on the dSYM bundle -- they both have debug information in them. dwarfdump won't find any debug information in your output executable.

因此，正常的工作流程:使用-g进行编译.链接可执行映像.如果是迭代开发，请运行调试器.如果要运送/存档二进制文件，请创建dSYM，剥离可执行文件.

So, the normal workflow: Compile with -g. Link executable image. If iterative development, run debugger. If shipping/archiving the binary, create dSYM, strip executable.

这篇关于LLDB没有显示源代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！