根据这个问题，我无法让 LLDB 在调试时显示实际的源代码。
感谢对该问题的公认答案，我已将问题追溯到 Tup 如何构建变体（例如调试、生产等）：
- 它在每个变体的子目录中工作
- 它不会将源复制到子目录中
- 它确实
.o在子目录中构建所有输出（文件和可执行文件本身）
正因为如此，LLDB在调试时找不到原始源文件。
所以我的问题是：我怎样才能强制 Tup 将不同的路径输入到构建过程中，或者告诉 LLDB 实际发生了什么？
问问题
1366 次
1 回答
2
我能够分两部分解决这个问题：
1. 让 Tup 使用准确的路径
首先，为了使可执行文件引用.o它们实际位置的文件，必须使 Tup 在 chroot 中运行（更多信息在这里和文档中）。这是通过c在 Tup 命令中放置一个插入符号来完成的。
所以我的构建命令来自类似
: foreach code/*.cpp |> ^o compile %f^ $(COMPILER) $(COMPILER_FLAGS) %f -o %o |> %B.o {code_object_files}
至
: foreach code/*.cpp |> ^oc compile %f^ $(COMPILER) $(COMPILER_FLAGS) %f -o %o |> %B.o {code_object_files}`
这获得了进入可执行文件的正确路径，但.o文件仍然引用源文件，就好像它们在构建子目录中，而不是在主目录中，导致：
2.告诉LLDB去哪里找源码
所以 LLDB 认为源是在，/Users/leo/project/subdirectory/code但它们实际上是在/Users/leo/project/code. 通过告诉 LLDB 用一条路径替换另一条路径来解决这个问题：
(lldb) settings set target.source-map /Users/leo/project/subdirectory /Users/leo/project
（这似乎不适用于相对路径，这很遗憾，因为这意味着需要每个开发机器的解决方案。如果有人知道无论项目在哪里都可以工作的解决方案，那么请告诉我！）
您还可以通过让 LLDB 获取包含以下行的文件来自动执行此操作：lldb -s path/to/lldb/config/file.
于 2016-05-08T18:47:44.763 回答