When compiling my project with clang++, the path to the source files is apparently not included in the object code. This means that gdb is unable to find source files to display code with. For specific instances, I can use gdb's directory command to add a directory, but my project has a lot of source directories and this gets annoying very quickly.
在使用clang++编译我的项目时，源文件的路径显然不包含在目标代码中。这意味着gdb无法找到要显示代码的源文件。对于特定的实例，我可以使用gdb的目录命令来添加一个目录，但是我的项目有很多源目录，这让人非常不快。
When I switch my configuration to use g++, gdb simply finds all my source files.
当我将配置切换到使用g++时，gdb只会找到我所有的源文件。
This functionality worked clang++ 2.9 on Snow Leopard, but doesn't work with clang++ 3.1 on Lion. I have XCode 4.3.2.
这个功能在雪豹上使用了clang+ 2.9，但在Lion上不使用clang+ 3.1。我有XCode 4.3.2。
Is there a clang option that forces full paths to be used in object files? Might something else be wrong with my configuration?
是否存在强制在对象文件中使用完整路径的clang选项?我的配置有问题吗?
1 个解决方案
#1
4
I discovered this: the issue happens, when building projects with hierarchical makefiles. If a subdirectory has been built from a parent directory (in my makefile: make -w -C sub-dir) then gdb can not open the source file. When changing into the sub-dir and calling make just for this directory then gdb finds the source. You can verify this by searching the build-path in the generated object files. I used strings object-file | grep $HOME.
我发现:当使用分层makefile构建项目时，会发生问题。如果从父目录(在我的makefile: make -w -C子目录中)构建了子目录，那么gdb就不能打开源文件。当切换到子目录并为该目录调用make时，gdb将找到源代码。您可以通过在生成的对象文件中搜索构建路径来验证这一点。我使用字符串对象文件| grep $HOME。
I noticed also: this was not happen for one object file: this file has not been compiled with CC. This file has been compiled with esql. At the end, esql calls CC.
我还注意到:对于一个对象文件来说，这是不可能的:这个文件不是用CC编译的，这个文件是用esql编译的。最后，esql调用CC。
That's why I tried this workaround: don't call clang directly from make. Call clang from a shell script.
这就是为什么我尝试了这个方法:不要直接打电话给clang。从shell脚本调用clang。
$ cat ~/bin/mycc
/usr/bin/cc "$@"
$ export CC=mycc
$ make
Hurray! gdb opens the source files!
华友世纪!gdb打开源文件!
BTW: replacing make -w -C sub-dir by (cd sub-dir;make -w) is another workaround.
顺便说一句:用cd子目录替换make -w -C子目录是另一个解决方案。
#1
4
I discovered this: the issue happens, when building projects with hierarchical makefiles. If a subdirectory has been built from a parent directory (in my makefile: make -w -C sub-dir) then gdb can not open the source file. When changing into the sub-dir and calling make just for this directory then gdb finds the source. You can verify this by searching the build-path in the generated object files. I used strings object-file | grep $HOME.
我发现:当使用分层makefile构建项目时，会发生问题。如果从父目录(在我的makefile: make -w -C子目录中)构建了子目录，那么gdb就不能打开源文件。当切换到子目录并为该目录调用make时，gdb将找到源代码。您可以通过在生成的对象文件中搜索构建路径来验证这一点。我使用字符串对象文件| grep $HOME。
I noticed also: this was not happen for one object file: this file has not been compiled with CC. This file has been compiled with esql. At the end, esql calls CC.
我还注意到:对于一个对象文件来说，这是不可能的:这个文件不是用CC编译的，这个文件是用esql编译的。最后，esql调用CC。
That's why I tried this workaround: don't call clang directly from make. Call clang from a shell script.
这就是为什么我尝试了这个方法:不要直接打电话给clang。从shell脚本调用clang。
$ cat ~/bin/mycc
/usr/bin/cc "$@"
$ export CC=mycc
$ make
Hurray! gdb opens the source files!
华友世纪!gdb打开源文件!
BTW: replacing make -w -C sub-dir by (cd sub-dir;make -w) is another workaround.
顺便说一句:用cd子目录替换make -w -C子目录是另一个解决方案。