在MacOS中调试Numba [英] Debugging Numba in MacOS

问题描述

问题

使用numba运行某些模拟时，我遇到了一个细分错误(该过程以退出代码139完成(信号11:SIGSEGV中断).

I get a segmentation error when using numba to run some simulations (Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)).

我正在尝试按照numba文档上的说明进行操作( https://numba.pydata.org/numba-doc/dev/user/troubleshoot.html#example-debug-usage )，但是我无法在MacOS上安装GDB.

I am trying to follow the instructions on the numba docs (https://numba.pydata.org/numba-doc/dev/user/troubleshoot.html#example-debug-usage) but I cannot install GDB on my MacOS.

MacOS上的GDB

我已按照此站点上的说明在MacOS https://www.thomasvitale.com/how-to-setup-gdb-and-eclipse-to-debug-c-files-on-macos-sierra /， 但是，在执行

I have followed the instructions on this site to install GDB on MacOS https://www.thomasvitale.com/how-to-setup-gdb-and-eclipse-to-debug-c-files-on-macos-sierra/, however when executing

$ gdb python

在终端上，我收到以下警告，使我无法调试代码:

on the terminal, I get the following warning which prevents me from being able to debug the code:

warning: `/tmp/lto.o': can't open to read symbols: No such file or directory.
(No debugging symbols found in python)

lldb和Numba

我尝试过的另一个选项是使用lldb调试Numba，但是它似乎不起作用.

The other option I have tried is to debug Numba using lldb, however it does not seem to work.

因此，我的问题是:如何在MacOS上调试Numba?

Therefore, my question is: how can debug Numba on a MacOS?

推荐答案

macOS处理调试信息的方式与其他系统略有不同.在大多数Unix系统上，编译器将调试信息发送到.o文件中.然后，链接器将调试信息复制到最终的可执行文件中.然后，调试器从可执行文件中读取调试信息.由于调试信息通常很大，因此需要大量复制...因此，在macOS上，我们将调试信息保留在.o文件中，而链接程序将调试映射"写入可执行文件.查找.o文件和调试器是调试器的工作.使用调试图链接调试信息.

The way macOS handles debug information is a little different from other systems. On most Unix systems, the compiler emits debug information into a .o file. Then the linker copies the debug information into the final executable. Then the debugger reads the debug info from the executable. Since debug info is generally pretty big that's a lot of copying... So on macOS we leave the debug info in the .o file, and instead the linker writes a "debug map" into the executable. It's the debugger's job to find the .o files & use the debug map to link up the debug info.

听起来像您正在使用"lto"(链接时间优化)使用它的构建过程一样，该过程将获取所有.o文件并构建单个.o文件，然后将其链接.这对于优化目的非常有用，因为您现在可以跨编译单元边界和诸如此类的其他巧妙技巧来内联函数.

It sounds like the build process you are using it using "lto" (Link Time Optimization) which takes all the .o files and builds a single .o file, which is then linked. That is great for optimization purposes because you can now inline functions across compile unit boundaries and other neat tricks like that.

但是该临时lto输出文件需要保留，以便调试工作.看来这在您的构建过程中没有发生.

But that temporary lto output file needs to be preserved for debugging to work. And it looks like that is not happening in your build process.

还有另一个步骤可以在macOS上调试信息.如果要长期存储调试信息，则必须保留所有.o文件会很烦人，因此有一个工具(dsymutil)将调试信息从.o文件复制到".dSYM"捆绑包中.您可能会看到您的构建过程中是否有关于dSYM的内容，这可能就是它如何保留来自构建的调试信息?

There's another step to debug information on macOS. If you want to store debug info longer term, it would be annoying to have to keep all the .o files around, so there's a tool (dsymutil) that copies the debug info from the .o files into a ".dSYM" bundle. You might see if your build process says anything about dSYM's, that might be how it preserves the debug info from the build?

这篇关于在MacOS中调试Numba的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！