Cuda-gdb不停止在内核中的断点 [英] Cuda-gdb not stopping at breakpoints inside kernel

问题描述

Cuda-gdb服从所有我设置的断点，然后在编译时添加-arch sm_20标志。我不得不添加这个，以避免错误被抛出：'atomicAdd is undefined'（指向这里）。这是我当前的语句来编译代码：

  nvcc -g -G --maxrregcount = 32 Main.cu -o SW_exe （..including头文件...）-arch sm_20 
  

，cuda-gdb在内核的最后一行停止一次，然后程序继续。

 （cuda-gdb）b SW_kernel_1.cu:49 
在0x4114a0处的断点1：文件./SW_kernel_1.cu，第49行。
 ... 
 [CUDA内核5的启动（对角线计算< ，1,1），（128,1,1）>>）on device 0] 
 
断点1，对角线计算（__cuda_0 = 15386，__cuda_1 = 128，__cuda_2 = 0xf00400000，__cuda_3 = 0xf00200000，
 __cuda_4 = 100，__cuda_5 = 0xf03fa0000，__cuda_6 = 0xf04004000，__cuda_7 = 0xf040a0000，__cuda_8 = 0xf00200200，
 __cuda_9 = 15258，__cuda_10 = 5，__cuda_11 = -3，__cuda_12 = 8，__cuda_13 = 1）at ./SW_kernel_1.cu:183 
 183} 
（cuda-gdb）c 
续。 
 

但是正如我所说，如果我删除'atomicAdd（）'调用和标志' sm_20'虽然使我的代码不正确，但现在cuda-gdb停止在我指定的断点。请告诉我这种行为的原因。
我在Tesla M2070上使用CUDA 5.5（Compute Capability = 2.0）。

谢谢！

解决方案

从CUDA DEBUGGER用户手册，第3.3.1节：

NVCC ，NVIDIA CUDA编译器驱动程序，提供了一种机制，用于生成CUDA-GDB正常工作所需的
调试信息。当编译应用程序时，必须将 -g -G 选项
对传递给NVCC debug用
CUDA-GDB;例如





  nvcc -g -G foo.cu -o foo 
  
 
 
 
 
 
使用此行编译CUDA应用程序foo.cu 
 
 
强制 -O0 编译，除非非常有限的死代码删除
和register- 
 
 
 
 
 
 $ b $  
  b 
这意味着，原则上，即使在调试模式下编译代码时，也不能在内核函数中触发断点，因为CUDA编译器可以执行一些代码优化，因此反汇编代码不能对应于CUDA指令。 
 
 
 
当未命中断点时，解决方法是在变量要检查后立即放置一个 printf 语句，如Robert Crovella在
建议
 
 
 使用VS的CUDA调试无法检查限制指针（操作无效） 
 
 
 
 OP在这里选择了一个不同的解决方法，即为不同的架构编译。事实上，编译器可以从架构到架构进行优化。
 
Cuda-gdb was obeying all the breakpoints I would set, before adding '-arch sm_20' flag while compiling. I had to add this to avoid error being thrown : 'atomicAdd is undefined' (as pointed here). Here is my current statement to compile the code:
nvcc -g -G --maxrregcount=32 Main.cu -o SW_exe (..including header files...) -arch sm_20 
and when I set a breakpoint inside kernel, cuda-gdb stops once at the last line of the kernel, and then the program continues.
(cuda-gdb) b SW_kernel_1.cu:49
Breakpoint 1 at 0x4114a0: file ./SW_kernel_1.cu, line 49.
...
[Launch of CUDA Kernel 5 (diagonalComputation<<<(1024,1,1),(128,1,1)>>>) on Device 0]

Breakpoint 1, diagonalComputation (__cuda_0=15386, __cuda_1=128, __cuda_2=0xf00400000, __cuda_3=0xf00200000, 
__cuda_4=100, __cuda_5=0xf03fa0000, __cuda_6=0xf04004000, __cuda_7=0xf040a0000, __cuda_8=0xf00200200, 
__cuda_9=15258, __cuda_10=5, __cuda_11=-3, __cuda_12=8, __cuda_13=1) at ./SW_kernel_1.cu:183
183     }
(cuda-gdb) c
Continuing.
But as I said, if I remove the 'atomicAdd()' call and the flag '-arch sm_20' which though makes my code incorrect, but now the cuda-gdb stops at the breakpoint I specify. Please tell me the reasons of this behaviour.

I am using CUDA 5.5 on Tesla M2070 (Compute Capability = 2.0).

Thanks!
解决方案
From the CUDA DEBUGGER User Manual, Section 3.3.1:

  
NVCC, the NVIDIA CUDA compiler driver, provides a mechanism for generating the
  debugging information necessary for CUDA-GDB to work properly. The -g -G option
  pair must be passed to NVCC when an application is compiled in order to debug with
  CUDA-GDB; for example,


nvcc -g -G foo.cu -o foo



  
Using this line to compile the CUDA application foo.cu

  
forces -O0 compilation, with the exception of very limited dead-code eliminations
  and register-spilling optimizations.
  
makes the compiler include debug information in the executable
  

This means that, in principle, breakpoints could not be hit in kernel functions even when the code is compiled in debug mode since the CUDA compiler can perform some code optimizations and so the disassembled code could not correspond to the CUDA instructions. 

When breakpoints are not hit, a workaround is to put a printf statement immediately after the variable one wants to check, as suggested by Robert Crovella at

CUDA debugging with VS - can't examine restrict pointers (Operation is not valid)

The OP has chosen here a different workaround, i.e., to compile for a different architecture. Indeed, the optimization the compiler does can change from architecture to architecture.

                        
这篇关于Cuda-gdb不停止在内核中的断点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！