根据这个问题,我无法让 LLDB 在调试时显示实际的源代码。
感谢对该问题的公认答案,我已将问题追溯到 Tup 如何构建变体(例如调试、生产等):
- 它在每个变体的子目录中工作
- 它不会将源复制到子目录中
- 它确实
.o
在子目录中构建所有输出(文件和可执行文件本身)
正因为如此,LLDB在调试时找不到原始源文件。
所以我的问题是:我怎样才能强制 Tup 将不同的路径输入到构建过程中,或者告诉 LLDB 实际发生了什么?
我能够分两部分解决这个问题:
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
.