如何在 XCode 中调试 DYLIB？
我是一位经验丰富的 Visual Studio 开发人员，最近接手了一个 OSX 10.6 项目（一个没有 UI 的 C++ 服务器项目）。
我已经使用 XCode 调试器（设置断点等）成功调试应用程序几个月了，包括调试链接到最终可执行程序的各种静态库的源代码。
然而，今晚我需要调试（使用断点）一个 DYLIB，该 DYLIB 也是根据我们的源代码构建的，但在运行时与应用程序动态链接（DYLIB 的名称由主应用程序从 .ini 文件中读取） ）。
不幸的是，我使用的调试应用程序的常用方法（右键单击自定义可执行文件并选择“使用断点调试”），尽管它确实成功运行了调试器并允许我调试应用程序（及其静态链接库），当我尝试在 DYLIB 源代码中命中断点时，出现以下不良行为：
-> XCode 调试器报告断点已命中，因为我在 XCode 窗口底部的状态栏中看到了函数和行号（以及表明这是一条 gdb 消息的指示），并且应用程序停止执行。然而，没有堆栈跟踪，没有变量，什么都没有——只是一个完全空的调试器窗口。 “跨过”、“跨入”等按钮被禁用。调试器中没有出现编辑器窗口（因此没有视觉指示表明调试器已停止在指示的行上）。手动打开文件不会显示调试器命中线路。
不幸的是，就我尝试调试 DYLIB 而言，这对我来说毫无用处。
今晚我进行了广泛的研究，并试图找到一种方法，让 XCode 调试器能够在这个动态链接的 DYLIB 的源代码中以有意义的方式成功命中断点。当然，我已经完成了一些清理/重建工作。我已经确定“惰性加载符号”未被选中，然后清理/重建。我已经重新启动，并且还删除了“build”目录并重新构建。我还删除了 .xcodeproj 包中的用户特定文件。 （另请注意，我当然是在关闭所有优化的开发模式下构建和运行所有代码，包括 DYLIB 代码，并为所有代码生成调试符号。）但是，我的尝试没有成功。我在互联网论坛上也找不到关于这个问题的任何提及。
任何指导我如何使用 XCode 成功调试链接到我的应用程序的 DYLIB 的帮助将不胜感激。
谢谢， 担。
I am an experienced Visual Studio developer who has recently taken on an OSX 10.6 project (a C++ server project with no UI).
I have been successfully debugging the application using the XCode debugger (setting breakpoints, etc.) for months, including debugging the source code for various static libraries that are linked into the final executable program.
However, tonight I was required to debug (with breakpoints) a DYLIB that is also built from our source code, but that is linked dynamically at runtime with the application (the name of the DYLIB is read from an .ini file by the main application).
Unfortunately, the usual method I use of debugging the application (right-clicking the custom executable and selecting "Debug with Breakpoints"), though it does successfully run the debugger and allow me to debug the application (along with its statically linked libraries), exhibits the following undesired behavior when I attempt to hit a breakpoint in the source code for the DYLIB:
-> The XCode debugger reports that the breakpoint was hit in the sense that I see the function and line number in the status bar at the bottom of the XCode windows (along with an indication that this is a gdb message), and the application halts execution. However, there is no stack trace, no variables, nothing - just a completely empty debugger window. The buttons to to "step over", "step into", etc, are disabled. No editor window appears in the debugger (and hence no visual indication that the debugger has stopped on the line indicated). Opening the file by hand does not reveal the debugger hitting the line.
Unfortunately, this is useless for me as far as my attempts to debug the DYLIB.
I have hunted far and wide tonight researching and attempting to find a way for the XCode debugger to successfully hit breakpoints in a meaningful way in the source code for this dynamically linked DYLIB. I have of course done a number of clean/rebuilds. I have made certain that "load symbols lazily" is unchecked and then cleaned/rebuilt. I have restarted, and I have also deleted the "build" directory and rebuilt. I also deleted the user-specific files in the .xcodeproj package. (Note also that I am of course building and running all code, including the DYLIB code, in Development mode with all optimizations off, and generating debug symbols for all.) However, my attempts have been unsuccessful. Nor can I find so much as a single mention of this problem on internet forums.
Any help in instructing me how to use XCode to successfully debug a DYLIB that is linked to my application would be appreciated.
Thanks,
Dan.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
更新-
此问题已解决。由于我缺乏 OSX 经验，导致我没有看到这一点。尽管事实上我的 DYLIB 项目与调用它的可执行文件属于同一个 XCode 项目，并且尽管 DYLIB 与可执行文件构建在同一目录中，但在运行时，调试的应用程序并未从此访问 DYLIB地点。相反，它是从（不同的）安装位置访问它。截至目前，我还没有找到安装位置“烹饪”到应用程序中的位置，而是通过将最终的可执行文件/DYLIB 复制到预期的安装位置并创建一个新的自定义可执行文件来指向该位置中的可执行文件，进行调试DYLIB 和可执行文件都有效。
谢谢，
担。
Update -
This problem is resolved. It was my lack of experience with OSX that caused me to fail to see this. Despite the fact that my DYLIB project was part of the same XCode project as the executable that calls it, and despite the fact that the DYLIB was built in the same directory as the executable, at runtime the debugged application was not accessing the DYLIB from this location. Instead, it was accessing it from a (different) install location. I have not as of this moment tracked down where the install location is "cooked" into the application, but by copying the final executable/DYLIB into the expected install location and creating a new custom executable that points to the executable in this location, debugging of both the DYLIB and the executable works.
Thanks,
Dan.