调试符号不包括在gcc编译的C++； 我正在构建一个C++中的模块，用于Python。我的流程是三个步骤：我将单个C++源编译成对象，创建一个库，然后运行一个StupU.Py脚本编译.Pyx>>CPP>。因此，在参考刚才创建的库时，

我知道我可以用Cython setup.py一步完成所有事情，这就是我过去的做法。将它分解成多个步骤的原因是我希望C++代码自行进化，在这种情况下，我只会使用Cython /Python中的编译库。 因此，当没有bug时，这个流工作得很好。问题是我正在试图找到segfault的源代码，所以我想获得调试符号，这样我就可以使用gdb运行了（我安装在osx10.14上，这很痛苦，但很有效）

我有一个makefile，它执行以下操作

步骤1：编译单个C++源文件 所有文件都使用最小标志编译，但是-g存在：

gcc -mmacosx-version-min=10.7 -stdlib=libc++ -std=c++14 -c -g -O0 -I ./csrc -o /Users/colinww/system-model/build/data_buffer.o csrc/data_buffer.cpp

我认为即使在这里也存在一个问题：当我执行nm-pa data_buffer.o时，我看不到调试符号。此外，我得到：

(base) cmac-2:system-model colinww$ dsymutil build/data_buffer.o
warning: no debug symbols in executable (-arch x86_64)

步骤2：编译cython源代码 makefile有一行

cd $(CSRC_DIR) && CC=$(CC) CXX=$(CXX) python3 setup_csrc.py build_ext --build-lib $(BUILD)

setup.py的相关部分包括

....
....
....
compile_args = ['-stdlib=libc++', '-std=c++14', '-O0', '-g']
link_args = ['-stdlib=libc++', '-g']
....
....
....
      Extension("circbuf",
                ["circbuf.pyx"],
                language="c++",
                libraries=["cpysim"],
                include_dirs = ['../build'],
                library_dirs=['../build'],
                extra_compile_args=compile_args,
                extra_link_args=link_args),
....
....
....
ext = cythonize(extensions,
                gdb_debug=True,
                compiler_directives={'language_level': '3'})

setup(ext_modules=ext,
      cmdclass={'build_ext': build_ext},
      include_dirs=[np.get_include()])

运行此命令时，它会生成一系列编译/链接命令，如

gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/colinww/anaconda3/include -arch x86_64 -I/Users/colinww/anaconda3/include -arch x86_64 -I. -I../build -I/Users/colinww/anaconda3/lib/python3.7/site-packages/numpy/core/include -I/Users/colinww/anaconda3/include/python3.7m -c circbuf.cpp -o build/temp.macosx-10.7-x86_64-3.7/circbuf.o -stdlib=libc++ -std=c++14 -O0 -g

及

在这两个命令中，-g标志都存在

步骤3：运行调试器 最后，我用gdb运行我的程序

(base) cmac-2:sim colinww$ gdb python3
(gdb) run system_sim.py

它转储了大量与系统文件相关的内容（似乎无关），最后运行我的程序，当它出现故障时：

Thread 2 received signal SIGSEGV, Segmentation fault.
0x0000000a4585469e in cpysim::DataBuffer<double>::Write(long, long, double) () from /Users/colinww/system-model/build/circbuf.cpython-37m-darwin.so
(gdb) info local
No symbol table info available.
(gdb) where
#0  0x0000000a4585469e in cpysim::DataBuffer<double>::Write(long, long, double) () from /Users/colinww/system-model/build/circbuf.cpython-37m-darwin.so
#1  0x0000000a458d6276 in cpysim::ChannelFilter::Filter(long, long, long) () from /Users/colinww/system-model/build/chfilt.cpython-37m-darwin.so
#2  0x0000000a458b0d29 in __pyx_pf_6chfilt_6ChFilt_4filter(__pyx_obj_6chfilt_ChFilt*, long, long, long) () from /Users/colinww/system-model/build/chfilt.cpython-37m-darwin.so
#3  0x0000000a458b0144 in __pyx_pw_6chfilt_6ChFilt_5filter(_object*, _object*, _object*) () from /Users/colinww/system-model/build/chfilt.cpython-37m-darwin.so
#4  0x000000010002f1b8 in _PyMethodDef_RawFastCallKeywords ()
#5  0x000000010003be64 in _PyMethodDescr_FastCallKeywords ()

非常感谢您的帮助，谢谢

更新 我删除了gcc标签并将其更改为clang。所以我想现在我很困惑，如果苹果将gcc别名为clang，这不意味着在“那种模式”下它应该像gcc一样工作（并且，暗示着，有人确保它是这样的）

更新2

---

因此，我永远无法让调试符号出现在调试器中，不得不求助于许多有趣的if-printf语句，但问题是由于索引变量未定义。因此，感谢所有的建议，但问题或多或少已经解决（直到下次）。谢谢

macOS链接器不会像其他Unixen上的链接器那样将调试信息链接到最终二进制文件中。相反，它将调试信息保留在.o文件中，并将“调试映射”写入二进制文件，告诉调试器如何查找和链接从.o文件读取的调试信息。剥离二进制文件时，将剥离调试映射

因此，您必须确保在最后一个链接之后不会移动或删除.o文件，并且在调试之前不会删除正在调试的二进制文件

您可以通过执行以下操作来检查是否存在调试映射：

$ nm -ap <PATH_TO_BINARY> | grep OSO

$nm-ap | grep OSO

您应该看到如下输出：

00000000 5D152F51-03 0001 OSO/Path/To/Build/Folder/SomeFile.o

如果您没有看到可执行文件可能已被剥离。如果.o文件不存在，则有人会比应该的更早清理您的生成文件夹

---

我也不知道gdb是否知道如何读取macOS上的调试映射。如果存在调试映射项和.o文件，您可以尝试lldb，看看是否可以找到调试信息。如果可以，那么这很可能是一个关于macOS的gdb问题。如果OSO和.o文件都存在，那么我猜不出有什么地方出了问题，可能值得提出一个bug。

对于

c++

编译，最好使用

g++

而不是

gcc

。@TarickWelling在Mac上并不重要；无论是代码> GCC < /C>和<代码> G++< /C>只是Clang的别名（用C++支持准备好了，看看上面的配置选项），这不是GCC；它叮当作响。Mac把一个化名给另一个（啊！）。您应该重新标记并更改构建命令以减少混乱。谢谢，只是尝试了一下，它没有改变任何东西。我的印象是gcc，g++，都链接到引擎盖下的叮当声？生成的二进制文件似乎是相同的。请原谅我的困惑，我自己不是mac用户，所以我不知道这个复杂的问题。虽然将

c++

编译器映射到

c

编译器听起来很危险。据我所知，其他操作系统没有将

gcc

映射到clang，这会有点奇怪，因为

gcc

比

clang

旧。我使用的是自制的gcc-9，我遵循您的确切过程，在链接之前检查对象。我在OSO上没有任何符号。奇怪的是，现在我通过将LLDB连接到运行的Python进程来调试C++ Python模块，并且它似乎起作用了（源代码存在于调试器中）。所以我猜它是功能性的，只是没有按照每个人告诉我的方式运行。OSO符号不在对象文件中，它们被链接器插入到最终链接的图像中。

(base) cmac-2:system-model colinww$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

$ nm -ap <PATH_TO_BINARY> | grep OSO